subject:"\[whatwg\] framesets"


Thomas,

>What's wrong or missing in MSDN and/or Google Documentation Reader?
>http://msdn.microsoft.com/en-us/library/system.collections.generic.aspx
>http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5

The Google solution needs at least 1,100 lines of JavaScript (perhaps 
much more, can't get at all the code). I need 120.


The MSDN solution looks like a huge OS-dependent hack.

As is, both expose node bookmarking, and I can't make out how either 
would behave if tree pruning & node edits were added.


PB

Re: [whatwg] framesets

2009-10-12 Thread Mike Ressler

Peter,

Thanks for the clarification, I think I have a little better understanding
now.

(Sorry I jumped into the mailing list in the middle of the conversation and
missed some of the earlier context) Are we currently discussing
implementation details around a proposed tree structure control?  I heard a
few people talk about framesets vs. frames vs. divs, but I thought the
proposal was that there would be a new  tag?  I guess my confusion
lies in why frames & framesets are being discussed at all.

The "black box" part of the tree view has me a little confused as well.  I
would think that such a structure would benefit greatly by allowing
JavaScript access to its elements.  And if such access to its internal
elements were available, then why wouldn't a developer simply implement one
of the many ways to block data bookmarking that you and I are aware of?

I was envisioning a  tag that would support expanding and collapsing
rows without forcing the developer to jump through fire-y JavaScript hoops
to get the implementation correct.  Then any modification to the tree would
be handled by the application developer via JavaScript or through a new page
view.  Am I way off base?

Mike Ressler


On Mon, Oct 12, 2009 at 12:01 PM, Peter Brawley wrote:

>  Mike,
>
> >Can you explain what you mean by "A DB row is a tree node and it must be
> possible
> >to block bookmarking of such rows." a little more?  From my understanding,
> a developer
> >could accomplish this with an onclick handler and some URI arguments, but
> it seems like
> >you're focused on the browser itself preventing the bookmarking of the
> link.
>
> There are good database reasons to block bookmarks to table rows, so that
> must be doable. That user requirement conflicts with the judgement, often
> voiced by HTML standards custodians, that frames are "bad" because they
> screw up bookmarking. The use case that mainly motivates my objection to
> this says that the datatree maintenance page must function as a black box
> with no internal HTML bookmarking at all---except for exit, navigation must
> be controlled entirely by database/tree logic. The argument is not,
> therefore, that HTML5 should support new methods of bookmark blocking. The
> argument is that for this use case, which is best served by framesets till
> proved otherwise (and no-one has yet), the bookmark objection to framesets
> is invalid.
>
> Yes I agree there are lots of ways to block data bookmarking.
>
> PB
>
> --
>
>
> Mike Ressler wrote:
>
> Peter,
>
> Can you explain what you mean by "A DB row is a tree node and it must be
> possible to block bookmarking of such rows." a little more?  From my
> understanding, a developer could accomplish this with an onclick handler and
> some URI arguments, but it seems like you're focused on the browser itself
> preventing the bookmarking of the link.
>
> What would preventing bookmarking by the browser accomplish that an onclick
> handler that rewrites the URI of the link not accomplish?
>
> Mike Ressler
>
> On Mon, Oct 12, 2009 at 11:21 AM, Peter Brawley 
> wrote:
>
>>  Ian,
>>
>> > 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.
>>
>> > 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.
>>
>> Supposing that someone can produce examples, the argument for removing
>> frames from HTML5 becomes: "frameset has been in HTML till now, /but is
>> being removed because we do not like it/. If you insist on such use
>> cases, re-architect them." That's a misuse of standards.
>>
>> >That's how we roll here. :-)
>>
>>  So I see. It's appalling.
>>
>> PB
>>
>> -
>>
>> Ian Hickson wrote:
>>
>>  On Thu, 8 Oct 2009, Peter Brawley wrote:
>>
>>
>>  According to http://www.w3.org/TR/2009/WD-html5-diff-20090825/, "The
>> following elements are not in HTML 5 because their usage affected
>> usability and accessibility for the end user in a negative way:
>>
>>* frame
>>* frameset
>>* noframes"
>>
>> As Andrew Fedoniouk said on this list in 2007
>> (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 conte

Re: [whatwg] framesets

2009-10-12 Thread Rimantas Liubertas

> There are good database reasons to block bookmarks to table rows, so that
> must be doable.

I still don't get what database has to do with it?
"block bookmars to table rows"? Does it make any sense at all?

<…>

Regards,
Rimantas
--
http://rimantas.com/

Re: [whatwg] framesets

2009-10-12 Thread Thomas Broyer

On Mon, Oct 12, 2009 at 6:01 PM, Peter Brawley  wrote:
> The use case that mainly motivates my objection to
> this says that the datatree maintenance page must function as a black box
> with no internal HTML bookmarking at all---except for exit, navigation must
> be controlled entirely by database/tree logic. The argument is not,
> therefore, that HTML5 should support new methods of bookmark blocking. The
> argument is that for this use case, which is best served by framesets till
> proved otherwise (and no-one has yet), the bookmark objection to framesets
> is invalid.

You have not proven why "this use case [...] is best served by
framesets" either. Actually, framesets alone don't answer your
requirement, you have to add:
 - a bit of JavaScript to use location.replace(...) in your links to
simulate a "single page application"
 - a bit of something to "block bookmarking" (user cannot use right
click -> open this frame in a new tab/window); unless we don't have
the same definition for "no internal HTML bookmarking"

I say that your use case is best served by AJAX (à la Google Document
Reader, just without the history trick using the location's hash).

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

Re: [whatwg] framesets

2009-10-12 Thread Thomas Broyer

On Mon, Oct 12, 2009 at 5:21 PM, 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.

What's wrong or missing in MSDN and/or Google Documentation Reader?
http://msdn.microsoft.com/en-us/library/system.collections.generic.aspx
http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

Re: [whatwg] framesets

Mike,

>Can you explain what you mean by "A DB row is a tree node and it must 
be possible
>to block bookmarking of such rows." a little more?  From my 
understanding, a developer
>could accomplish this with an onclick handler and some URI arguments, 
but it seems like
>you're focused on the browser itself preventing the bookmarking of the 
link.

There are good database reasons to block bookmarks to table rows, so 
that must be doable. That user requirement conflicts with the judgement, 
often voiced by HTML standards custodians, that frames are "bad" because 
they screw up bookmarking. The use case that mainly motivates my 
objection to this says that the datatree maintenance page must function 
as a black box with no internal HTML bookmarking at all---except for 
exit, navigation must be controlled entirely by database/tree logic. The 
argument is not, therefore, that HTML5 should support new methods of 
bookmark blocking. The argument is that for this use case, which is best 
served by framesets till proved otherwise (and no-one has yet), the 
bookmark objection to framesets is invalid.

Yes I agree there are lots of ways to block data bookmarking.

PB

--

Mike Ressler wrote:

Peter,

Can you explain what you mean by "A DB row is a tree node and it must 
be possible to block bookmarking of such rows." a little more?  From 
my understanding, a developer could accomplish this with an onclick 
handler and some URI arguments, but it seems like you're focused on 
the browser itself preventing the bookmarking of the link.

What would preventing bookmarking by the browser accomplish that an 
onclick handler that rewrites the URI of the link not accomplish?

Mike Ressler

On Mon, Oct 12, 2009 at 11:21 AM, Peter Brawley > wrote:

Ian,

> 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.

> 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.

Supposing that someone can produce examples, the argument for
removing
frames from HTML5 becomes: "frameset has been in HTML till now,
/but is
being removed because we do not like it/. If you insist on such use
cases, re-architect them." That's a misuse of standards.

>That's how we roll here. :-)

So I see. It's appalling.

PB

-

Ian Hickson wrote:

On Thu, 8 Oct 2009, Peter Brawley wrote:

According to http://www.w3.org/TR/2009/WD-html5-diff-20090825/, "The 
following elements are not in HTML 5 because their usage affected 
usability and accessibility for the end user in a negative way:

   * frame
   * frameset
   * noframes"

As Andrew Fedoniouk said on this list in 2007

(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 agree wholeheartedly, esp. when the topic list is long (thousands or 
millions of items) and itself editable, and the required interface is 
for flexible, independent scrolling of freely choosable bits of the 
topic tree in the left frame without affecting anything in the right 
detail frame. As Andrew said, frames are the only good way to do this.

New standards ought not to remove required functionalities, ought not to 
break perfectly good & legal working code, and ought not to impose 
Hobson's choice of keeping functionality vs remaining 
standards-compliant. How do we get the unwise decision to remove 
framesets revisited?

Except for resizing, anything you can do with framesets, you can do better 
with s and CSS. In addition, with pushState(), you can fix the 
bookmarking problem in a better way than with framesets.

Resizing is something that's harder to do, but that's a presentational 
issue that we need to fix anyway, independent of frames.

Framesets have a number of problems, chief amongst them that bookmarking 
is dysfunctional, but also that the accessibility story for frames is 
rather poor, and that there the presentation with fram

Re: [whatwg] framesets

2009-10-12 Thread Tab Atkins Jr.

On Mon, Oct 12, 2009 at 10:21 AM, Peter Brawley  wrote:
> A DB row is a tree node and it must be possible to block bookmarking of such
> rows.

You keep implying that frames make it possible to block bookmarking.
They do not.  Anyone can right click->open frame and then just
bookmark that page.

Frames do make it more difficult for the casual user to bookmark
things, but if you're relying on this for some sort of security,
you're being very naive in believing that *anything* client-side will
work.  You need to implement this protection server-side for it to be
reliable.  Frames are not the correct answer to this requirement.

~TJ

Re: [whatwg] framesets

2009-10-12 Thread Mike Ressler

Peter,

Can you explain what you mean by "A DB row is a tree node and it must be
possible to block bookmarking of such rows." a little more?  From my
understanding, a developer could accomplish this with an onclick handler and
some URI arguments, but it seems like you're focused on the browser itself
preventing the bookmarking of the link.

What would preventing bookmarking by the browser accomplish that an onclick
handler that rewrites the URI of the link not accomplish?

Mike Ressler

On Mon, Oct 12, 2009 at 11:21 AM, Peter Brawley wrote:

>  Ian,
>
> > 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.
>
> > 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.
>
> Supposing that someone can produce examples, the argument for removing
> frames from HTML5 becomes: "frameset has been in HTML till now, /but is
> being removed because we do not like it/. If you insist on such use
> cases, re-architect them." That's a misuse of standards.
>
> >That's how we roll here. :-)
>
> So I see. It's appalling.
>
> PB
>
> -
>
> Ian Hickson wrote:
>
> On Thu, 8 Oct 2009, Peter Brawley wrote:
>
>
>  According to http://www.w3.org/TR/2009/WD-html5-diff-20090825/, "The
> following elements are not in HTML 5 because their usage affected
> usability and accessibility for the end user in a negative way:
>
>* frame
>* frameset
>* noframes"
>
> As Andrew Fedoniouk said on this list in 2007
> (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 agree wholeheartedly, esp. when the topic list is long (thousands or
> millions of items) and itself editable, and the required interface is
> for flexible, independent scrolling of freely choosable bits of the
> topic tree in the left frame without affecting anything in the right
> detail frame. As Andrew said, frames are the only good way to do this.
>
> New standards ought not to remove required functionalities, ought not to
> break perfectly good & legal working code, and ought not to impose
> Hobson's choice of keeping functionality vs remaining
> standards-compliant. How do we get the unwise decision to remove
> framesets revisited?
>
>
>  Except for resizing, anything you can do with framesets, you can do better
> with s and CSS. In addition, with pushState(), you can fix the
> bookmarking problem in a better way than with framesets.
>
> Resizing is something that's harder to do, but that's a presentational
> issue that we need to fix anyway, independent of frames.
>
> Framesets have a number of problems, chief amongst them that bookmarking
> is dysfunctional, but also that the accessibility story for frames is
> rather poor, and that there the presentation with frames is much less
> pleasing than with other features (e.g. in Safari, this page:
>
>http://www.artfulsoftware.com/infotree/mysqlquerytree.php
>
> ...has a vertical scrollbar for the top frame -- a problem you wouldn't
> get if instead of four pages, you had three, with the main one containing
> two iframes from the left and right frames).
>
> In addition to s, other techniques exist to get similar results,
> e.g. AJAX. The use case covered by  is definitely handled
>
> (Getting rid of the frames altogether is probably best, since then tools
> like search engines can actually return useful links. However, I
> understand if some authors are unwilling to do the work to get to that
> point. , on the other hand, are very easy to migrate to.)
>
>
> On Fri, 9 Oct 2009, Peter Brawley wrote:
>
>
>  W3C's job is to enable, not function like a commissariat.
>
>
>  This isn't the W3C.
>
>
> On Fri, 9 Oct 2009, Peter Brawley wrote:
>
>
>  I'm arguing that framesets have been part of HTML4, developers used them
> in good faith, and removing them from HTML5 unfairly & arbitrarily
> imposes a Hobson's choice of keeping existing functionality while
> foregoing new HTML5 functionality, or re-architecting existing
> functionality in order to use new HTML5 functionality.
>
>
>  Actually, you only need to use frames in the frameset page, so if your
> only concern is what validates, y

Re: [whatwg] framesets

Ian,

> 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.

> 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.

Supposing that someone can produce examples, the argument for removing
frames from HTML5 becomes: "frameset has been in HTML till now, /but is
being removed because we do not like it/. If you insist on such use
cases, re-architect them." That's a misuse of standards.

>That's how we roll here. :-)

So I see. It's appalling.

PB

-

Ian Hickson wrote:

On Thu, 8 Oct 2009, Peter Brawley wrote:

According to http://www.w3.org/TR/2009/WD-html5-diff-20090825/, "The 
following elements are not in HTML 5 because their usage affected 
usability and accessibility for the end user in a negative way:

   * frame
   * frameset
   * noframes"

As Andrew Fedoniouk said on this list in 2007
(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 agree wholeheartedly, esp. when the topic list is long (thousands or 
millions of items) and itself editable, and the required interface is 
for flexible, independent scrolling of freely choosable bits of the 
topic tree in the left frame without affecting anything in the right 
detail frame. As Andrew said, frames are the only good way to do this.

New standards ought not to remove required functionalities, ought not to 
break perfectly good & legal working code, and ought not to impose 
Hobson's choice of keeping functionality vs remaining 
standards-compliant. How do we get the unwise decision to remove 
framesets revisited?

Except for resizing, anything you can do with framesets, you can do better 
with s and CSS. In addition, with pushState(), you can fix the 
bookmarking problem in a better way than with framesets.

Resizing is something that's harder to do, but that's a presentational 
issue that we need to fix anyway, independent of frames.

Framesets have a number of problems, chief amongst them that bookmarking 
is dysfunctional, but also that the accessibility story for frames is 
rather poor, and that there the presentation with frames is much less 
pleasing than with other features (e.g. in Safari, this page:

   http://www.artfulsoftware.com/infotree/mysqlquerytree.php

...has a vertical scrollbar for the top frame -- a problem you wouldn't 
get if instead of four pages, you had three, with the main one containing 
two iframes from the left and right frames).

In addition to s, other techniques exist to get similar results, 
e.g. AJAX. The use case covered by  is definitely handled 

(Getting rid of the frames altogether is probably best, since then tools 
like search engines can actually return useful links. However, I 
understand if some authors are unwilling to do the work to get to that 
point. , on the other hand, are very easy to migrate to.)

On Fri, 9 Oct 2009, Peter Brawley wrote:

W3C's job is to enable, not function like a commissariat.

This isn't the W3C.

On Fri, 9 Oct 2009, Peter Brawley wrote:

I'm arguing that framesets have been part of HTML4, developers used them 
in good faith, and removing them from HTML5 unfairly & arbitrarily 
imposes a Hobson's choice of keeping existing functionality while 
foregoing new HTML5 functionality, or re-architecting existing 
functionality in order to use new HTML5 functionality.

Actually, you only need to use frames in the frameset page, so if your 
only concern is what validates, you could just use HTML4 Frameset for the 
frameset page, and HTML5 for the content pages.

But I would still strongly discourage using framesets.

On Fri, 9 Oct 2009, Jonas Sicking wrote:

The big difference is that s can be used in good ways, framesets 
essentially can't.

Another reason do deprecate  but not  is that we don't 
need *two* ways to make poorly behaving pages.

Indeed.

On Fri, 9 Oct 2009, Peter Brawley wrote:

Supposing that someone can produce examples, the argument for removing 
frames from HTML5 becomes: "frameset has been in HTML till now, /but is 
being removed because we do not like it/. If you insist on such use 
cases, re-architect them." That'

Re: [whatwg] framesets

2009-10-12 Thread Markus Ernst


tali garsiel schrieb:

 
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


I guess it's not a HTML5 question but more a "best practice" question but ...
In case an application has navigation menus that cannot be reloaded each 
time.Only the content part should be reloaded.

What is a better

1. Using an iframe for the content and fixing bookmarking/back button
2. Using Ajax to update the content - a "single document application"

The issue with the later option is not user experience but browser performance.
Is never reloading the document, only updating the DOM harmful? (like caches 
wont be cleaned , garbage collection will not be done properly) .

Maybe it's browser specific but it also has to do with what browsers are 
supposed to support and test.


I assume that if you do care about search engines, the Ajax approach 
will require some amount of extra coding in order to make the content 
indexable.


Anyway, with extra coding you can also match most of Peter's 
requirements regarding user experience with a single-page solution. I am 
sure you can pass the state of the navigation tree via query string, and 
accordingly collapse or expand the nodes when a page is loaded. You can 
also pass the current scroll position of the page.


What may be missing is the possibility to pass the scroll position of 
the navigation or content, if they are in divs with overflow:scroll. I 
am not familiar enough with DOM - if they do not yet exist, it might be 
worth to consider enabling pageYOffset, pageXOffset, scrollBy() and 
scrollTo() for all element objects that can contain scrollable content 
rather than for the window object only.

Re: [whatwg] framesets

2009-10-12 Thread tali garsiel

Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0

I guess it's not a HTML5 question but more a "best practice" question but ...
In case an application has navigation menus that cannot be reloaded each 
time.Only the content part should be reloaded.

What is a better

1. Using an iframe for the content and fixing bookmarking/back button
2. Using Ajax to update the content - a "single document application"

The issue with the later option is not user experience but browser performance.
Is never reloading the document, only updating the DOM harmful? (like caches 
wont be cleaned , garbage collection will not be done properly) .

Maybe it's browser specific but it also has to do with what browsers are 
supposed to support and test.

> Date: Mon, 12 Oct 2009 11:46:37 +
> From: i...@hixie.ch
> To: t_gars...@hotmail.com
> CC: wha...@whatwg.org
> Subject: RE: [whatwg] framesets
>
> On Mon, 12 Oct 2009, tali garsiel wrote:
>>
>> Does "pushState" apply to bookmarking?
>
> Insofar as bookmarking uses the document's current address, yes.
> (Bookmarking, being a UI feature, isn't defined in HTML5.)
>
> --
> Ian Hickson U+1047E )\._.,--,'``. fL
> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

_
Windows Live: Make it easier for your friends to see what youre up to on 
Facebook.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009

Re: [whatwg] framesets

2009-10-12 Thread Ian Hickson

On Mon, 12 Oct 2009, tali garsiel wrote:
> 
> Does "pushState" apply to bookmarking?

Insofar as bookmarking uses the document's current address, yes. 
(Bookmarking, being a UI feature, isn't defined in HTML5.)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] framesets

2009-10-12 Thread tali garsiel



 

 
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


Does "pushState" apply to bookmarking ?From reading section 6.10 of the spec it 
seems to apply only to back/forward navigation.If it does, it seems a good 
solution for iframe bookmarking problem.
> Date: Mon, 12 Oct 2009 09:12:34 +
> From: i...@hixie.ch
> To: wha...@whatwg.org
> Subject: Re: [whatwg] framesets
> 
> On Thu, 8 Oct 2009, Peter Brawley wrote:
>>
>> According to http://www.w3.org/TR/2009/WD-html5-diff-20090825/, "The 
>> following elements are not in HTML 5 because their usage affected 
>> usability and accessibility for the end user in a negative way:
>>
>>* frame
>>* frameset
>>* noframes"
>> 
>> As Andrew Fedoniouk said on this list in 2007
>> (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 agree wholeheartedly, esp. when the topic list is long (thousands or 
>> millions of items) and itself editable, and the required interface is 
>> for flexible, independent scrolling of freely choosable bits of the 
>> topic tree in the left frame without affecting anything in the right 
>> detail frame. As Andrew said, frames are the only good way to do this.
>> 
>> New standards ought not to remove required functionalities, ought not to 
>> break perfectly good & legal working code, and ought not to impose 
>> Hobson's choice of keeping functionality vs remaining 
>> standards-compliant. How do we get the unwise decision to remove 
>> framesets revisited?
> 
> Except for resizing, anything you can do with framesets, you can do better 
> with s and CSS. In addition, with pushState(), you can fix the 
> bookmarking problem in a better way than with framesets.
> 
> Resizing is something that's harder to do, but that's a presentational 
> issue that we need to fix anyway, independent of frames.
> 
> Framesets have a number of problems, chief amongst them that bookmarking 
> is dysfunctional, but also that the accessibility story for frames is 
> rather poor, and that there the presentation with frames is much less 
> pleasing than with other features (e.g. in Safari, this page:
> 
>http://www.artfulsoftware.com/infotree/mysqlquerytree.php
> 
> ...has a vertical scrollbar for the top frame -- a problem you wouldn't 
> get if instead of four pages, you had three, with the main one containing 
> two iframes from the left and right frames).
> 
> In addition to s, other techniques exist to get similar results, 
> e.g. AJAX. The use case covered by  is definitely handled 
> 
> (Getting rid of the frames altogether is probably best, since then tools 
> like search engines can actually return useful links. However, I 
> understand if some authors are unwilling to do the work to get to that 
> point. , on the other hand, are very easy to migrate to.)
> 
> 
> On Fri, 9 Oct 2009, Peter Brawley wrote:
>>
>> W3C's job is to enable, not function like a commissariat.
> 
> This isn't the W3C.
> 
> 
> On Fri, 9 Oct 2009, Peter Brawley wrote:
>> 
>> I'm arguing that framesets have been part of HTML4, developers used them 
>> in good faith, and removing them from HTML5 unfairly & arbitrarily 
>> imposes a Hobson's choice of keeping existing functionality while 
>> foregoing new HTML5 functionality, or re-architecting existing 
>> functionality in order to use new HTML5 functionality.
> 
> Actually, you only need to use frames in the frameset page, so if your 
> only concern is what validates, you could just use HTML4 Frameset for the 
> frameset page, and HTML5 for the content pages.
> 
> But I would still strongly discourage using framesets.
> 
> 
> On Fri, 9 Oct 2009, Jonas Sicking wrote:
>> 
>> The big difference is that s can be used in good ways, framesets 
>> essentially can't.
>> 
>> Another reason do deprecate  but not  is that we don't 
>> need *two* ways to make poorly behaving pages.
> 
> Indeed.
> 
> 
> On Fri, 9 Oct 2009, Peter Brawley wrote:
>> 
>> Supposing that someone can produce examples, the argument for removing 
>> frames from HTML5 becomes: "frameset has been in HTML till now, /but is 
>> being removed because we do not like it/. If you insist on such use 
>> cases, re-architect

Re: [whatwg] framesets

2009-10-12 Thread Ian Hickson

On Thu, 8 Oct 2009, Peter Brawley wrote:
>
> According to http://www.w3.org/TR/2009/WD-html5-diff-20090825/, "The 
> following elements are not in HTML 5 because their usage affected 
> usability and accessibility for the end user in a negative way:
>
>* frame
>* frameset
>* noframes"
> 
> As Andrew Fedoniouk said on this list in 2007
> (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 agree wholeheartedly, esp. when the topic list is long (thousands or 
> millions of items) and itself editable, and the required interface is 
> for flexible, independent scrolling of freely choosable bits of the 
> topic tree in the left frame without affecting anything in the right 
> detail frame. As Andrew said, frames are the only good way to do this.
> 
> New standards ought not to remove required functionalities, ought not to 
> break perfectly good & legal working code, and ought not to impose 
> Hobson's choice of keeping functionality vs remaining 
> standards-compliant. How do we get the unwise decision to remove 
> framesets revisited?

Except for resizing, anything you can do with framesets, you can do better 
with s and CSS. In addition, with pushState(), you can fix the 
bookmarking problem in a better way than with framesets.

Resizing is something that's harder to do, but that's a presentational 
issue that we need to fix anyway, independent of frames.

Framesets have a number of problems, chief amongst them that bookmarking 
is dysfunctional, but also that the accessibility story for frames is 
rather poor, and that there the presentation with frames is much less 
pleasing than with other features (e.g. in Safari, this page:

   http://www.artfulsoftware.com/infotree/mysqlquerytree.php

...has a vertical scrollbar for the top frame -- a problem you wouldn't 
get if instead of four pages, you had three, with the main one containing 
two iframes from the left and right frames).

In addition to s, other techniques exist to get similar results, 
e.g. AJAX. The use case covered by  is definitely handled 

(Getting rid of the frames altogether is probably best, since then tools 
like search engines can actually return useful links. However, I 
understand if some authors are unwilling to do the work to get to that 
point. , on the other hand, are very easy to migrate to.)

On Fri, 9 Oct 2009, Peter Brawley wrote:
>
> W3C's job is to enable, not function like a commissariat.

This isn't the W3C.

On Fri, 9 Oct 2009, Peter Brawley wrote:
> 
> I'm arguing that framesets have been part of HTML4, developers used them 
> in good faith, and removing them from HTML5 unfairly & arbitrarily 
> imposes a Hobson's choice of keeping existing functionality while 
> foregoing new HTML5 functionality, or re-architecting existing 
> functionality in order to use new HTML5 functionality.

Actually, you only need to use frames in the frameset page, so if your 
only concern is what validates, you could just use HTML4 Frameset for the 
frameset page, and HTML5 for the content pages.

But I would still strongly discourage using framesets.

On Fri, 9 Oct 2009, Jonas Sicking wrote:
> 
> The big difference is that s can be used in good ways, framesets 
> essentially can't.
> 
> Another reason do deprecate  but not  is that we don't 
> need *two* ways to make poorly behaving pages.

Indeed.

On Fri, 9 Oct 2009, Peter Brawley wrote:
> 
> Supposing that someone can produce examples, the argument for removing 
> frames from HTML5 becomes: "frameset has been in HTML till now, /but is 
> being removed because we do not like it/. If you insist on such use 
> cases, re-architect them." That's a misuse of standards.

That's how we roll here. :-)

> >What'd be the point of keeping two sources of issues when one can be 
> >enough to cover all use-cases?
> 
> If your premiss is correct, backward compatibility.

Backwards-compatibility is preserved: HTML5 defines how framesets are to 
be implemented, so your pages won't stop working with HTML5 browsers. They 
just won't be conforming HTML5, because we want to discourage the use of 
framesets in favour of better solutions.

On Fri, 9 Oct 2009, Peter Brawley wrote:
> 
> Why relegate a perfectly sound use case to a cul-de-sac?

It would be a bad idea to relegate a perfectly sound use case to a 
cul-de-sac. But that's not what we're doing. The use case is still 
handled fine, in a number of ways (e.g. s, Ajax-based navigation). 
The feature we're relegating to a cul-de-sac is not perfectly sound.

On Fri, 9 Oct 2009, Peter Brawley wrote:
>
> It's not your brief to decide what's beneficial for a client.

Actually, it sort of is.

> >It conflicts with expected behavior.
> 
> It does not conflict with what these users expect.

Framesets actual

Re: [whatwg] framesets

Simon,

Thanks for the interest.

>I would presume that Peter is asking for frameset, frame and noframes
>to be part of the set of conforming elements in HTML. Correct, Peter?

Yep!

Simon Pieters wrote:
On Sun, 11 Oct 2009 23:43:03 +0200, Eduard Pascual
wrote:

For it to be taken
seriously by the editor, I strongly recommend that you send spec-ready
quality text,

I recommend sticking to use cases, requirements, links to real-world
pages, and proposed solutions with pros/cons.

is not being removed from HTML.

It's being removed from the set of conforming elements in HTML, along
with e.g. . It's not being removed from what browsers have to
implement: HTML5 specs frameset for browsers in the parsing, rendering
and obsolete features sections.

It's just not being updated
because there was nothing to add to it, so it stays the same.

Not really:

Elements in the following list are entirely obsolete, and must not be
used by authors:

frame
frameset
noframes

Either use iframe and CSS instead, or use server-side includes to
generate complete pages with the various invariant parts merged in.

http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#non-conforming-features

Taking all this together, here comes again: the question I have
already asked several times, and you haven't answered: What are you
asking for?

I would presume that Peter is asking for frameset, frame and noframes
to be part of the set of conforming elements in HTML. Correct, Peter?

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.421 / Virus Database: 270.14.9/2428 - Release Date: 10/11/09 06:39:00

Re: [whatwg] framesets

2009-10-12 Thread Simon Pieters

On Sun, 11 Oct 2009 23:43:03 +0200, Eduard Pascual   
wrote:



For it to be taken
seriously by the editor, I strongly recommend that you send spec-ready
quality text,


I recommend sticking to use cases, requirements, links to real-world  
pages, and proposed solutions with pros/cons.




 is not being removed from HTML.


It's being removed from the set of conforming elements in HTML, along with  
e.g. . It's not being removed from what browsers have to  
implement: HTML5 specs frameset for browsers in the parsing, rendering and  
obsolete features sections.




It's just not being updated
because there was nothing to add to it, so it stays the same.


Not really:

   Elements in the following list are entirely obsolete, and must not be
   used by authors:

   frame
   frameset
   noframes

  Either use iframe and CSS instead, or use server-side includes to
  generate complete pages with the various invariant parts merged in.

http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#non-conforming-features



Taking all this together, here comes again: the question I have
already asked several times, and you haven't answered: What are you
asking for?


I would presume that Peter is asking for frameset, frame and noframes to  
be part of the set of conforming elements in HTML. Correct, Peter?


--
Simon Pieters
Opera Software

Re: [whatwg] framesets

2009-10-11 Thread Henri Sivonen

I assume Javadocs are a legitimate use case for HTML5. What's the  
right way to implement Javadocs in HTML5?


--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] framesets

2009-10-11 Thread Peter Brawley


Eduard,


The requirements for a project are a completely
independent concept of the requirements for a feature on a
specification.


On that view of yours, I am wasting my time discussing the matter with you.

PB

Re: [whatwg] framesets

2009-10-11 Thread Mike Ressler

PB,

You could add an attribute to the link displayed by a tree control that
would cause the server to kick the user back to the tree view rather than
the row view, if that's what you're trying to prevent (direct access to leaf
elements of the tree).  Something like
http://www.example.com/leafView.htm?id=1&bookmarkMe=false.  Then when a user
bookmarks the link, the server can boot the user back to
http://www.example.com/treeView.htm.  When the user clicks on the link, just
have it fire off some JavaScript to change the URL to get rid of the
bookmarkMe=false attribute so the server allows the request to edit (or
view) that leaf entry.

Would that solve your bookmarking dilemma?  I like the idea of a tree
control (very much), but I was confused about the bookmarking issue.

Mike Ressler

On Sun, Oct 11, 2009 at 12:31 PM, Peter Brawley wrote:

>  Edouard,
>
> >1) Your example with phpMyAdmin (PMA for short) is slightly wrong (and
> >I'm speaking with several years of experience using it): I just did a
> >bit of testing on my PMA 2.11.9.4 installation and bookmarking works
> >fine down to a reasonable degree: of course, I can't bookmark a "row"
> >itself (wouldn't make much sense, as rows can appear and disappear
> >quite often), but I can bookmark most (almost all) of the "screens" of
> >PMA, such as "list of tables in db X", "insert new row on table Y",
>
> In a treeview, node=row, detail page=row. It must be possible to block
> bookmarking of individual rows and columns.
>
> >3) Finally, this may sound a bit too theoretical, but I think it's
> >worth pointing out: your idea of breaking bookmarking and similar
> >features, as described on your last mail, is not an actual
> >requirement: it seems to be your try at addressing the security
> >requirement.
>
> With all due respect, the client decides what the requirements are &
> aren't. This use case includes the requirement that the user be able to drop
> into and out of tree maintenance as if it were a black box. There are three
> main reasons for that: non-tree webnav convenience, restriction of node
> access mechanisms to those implemented by the webapp, avoidance of shortcut
> webnav access to specific rows.
>
> >Finally, you don't need to bother too much about how the HTML5 spec
> >will impact on browser support for deprecated and non-updated
> >features: it simply won't. It's a matter of offer and demand: as long
> >as there are  or  tags out there, browsers will be
> >able to handle them, regardless of what the spec may say (currently,
> >the spec just tries to make the different UAs agree on how to handle
> >these and worse things).
>
> In discussion of this issue elsewhere, absence of an HTML5 frameset spec is
> being touted as nailing the case for "framesets are evil, get rid of them".
> Obviously, absence of an HTML5 frameset spec enables that agenda. I do need
> to bother.
>
> Can I take your non-response to "You are not the first to claim that tables
> & iframes can meet this spec ... if it does I ought to have been able to
> find a working instance in the past six years or so, don't you think?" as
> agreement that there are serious reasons for preferring framesets to tables
> & iframes for this problem?
>
> PB
>
> -
>
> Eduard Pascual wrote:
>
> On Sun, Oct 11, 2009 at 3:12 AM, Peter Brawley  
>  wrote:
>
>
>  Edouard,
>
>
>
>  Use case: displaying tree-based content (editable or not). (Note: I'm
> omitting the database aspect because it only matters on the server
> side: once on the client, the page doesn't care whether the data comes
> from/goes to a database, a collection of files, or anywhere else).
>
>
>  I'm afraid that empties meaning from the use case, whose requirements
> significant to this discussion arise from the database context:
> (i) the required page is a database maintenance webapp,
>
>
>  Still, I think that matters on the server, but how much does it matter
> on the client? How does this affect the requirements for the
> client-side part of the application? Even if it really matters, which
> requirements for the use-case will be derived from this aspect?
>
>
>
>  (ii) the data it maintains is in the form of a tree, and
>
>
>  I think that was quite covered by the description "displaying
> tree-based content (editable or not)".
>
>
>
>  (iii) the objects of database maintenance (rows in the database tables which
> instantiate the tree) usually should not be bookmarkable for the same reason
> other database webapps (eg phpMyAdmin) do not bookmark database data---a
> bookmark belongs to a browser, but a row of database table data belongs not
> to a browser but to users who may CRUD it, and access to such objects must
> not be shortcutted. That is, database maintenance in a webapp depends at
> least partly on protecting data from some popular web mechanisms. If that
> offends HTML purists, or if this use case conflicts with an "original" idea
> about the web, so be it. For this context, HTML is just a device for getting
> usef

Re: [whatwg] framesets

2009-10-11 Thread Eduard Pascual

On Sun, Oct 11, 2009 at 6:31 PM, Peter Brawley  wrote:
> In a treeview, node=row, detail page=row. It must be possible to block
> bookmarking of individual rows and columns.
That's the default behavior with either frameset or table+iframe; and
it can even be achieved with the CSS-based approach (although that
would take a good deal of creativity). So, what's the issue? But
still, what is the goal of blocking bookmarking?

> With all due respect, the client decides what the requirements are & aren't.
With all due respect, most clients just don't know even what
"requirement" means. The requirements for a project are a completely
independent concept of the requirements for a feature on a
specification.
Just because a client says "a project must do X" doesn't mean that the
spec should address X. I have had clients asking to monitor their
visitor's computers (in some cases even with legitimate purposes):
trying to bring that as "requirements" to this list would have been a
waste of time. In summary, what a client labels as a "requirement" is
almost irrelevant.
If you are a developer, then you probably have more knowledge and
skills in the field. I'm convinced that you are capable enough of
extracting actual requirements from whatever your client is asking.
Actually, you got quite close:

> This use case includes the requirement that the user be able to drop into
> and out of tree maintenance as if it were a black box.
THAT is a requirement! Great. Now let's go into its justfication.
> There are three main reasons for that: non-tree webnav convenience,
Nice, that's a bit of justification. Up to this point (counting the
black-box requirement and the justification above), would it be the
same as something like this: "The tree app needs to be treated as a
black-box so it doesn't interfere with normal navigation through the
rest of the site"? Just want to make sure that I'm understanding your
meaning.
> restriction of node access mechanisms to those implemented by the webapp,
Sorry, but here you are asking something impossible. I have already
explained why access control can only be achieved on the server side.
I'll be ignoring this kind of "requirement" from now on until/unless
someone counters that statement.
> avoidance of shortcut webnav access to specific rows.
That seems quite a mixture of the two "reasons" above. If it really is
something separate from those, please clarify.
Anyway, even with just the first reason there is some justification.
Taking a brief look at it, this can be met through several approaches,
including , +, java/flash/silverlight/etc
(hey, those are really good at black-boxing); and can be hacked

> In discussion of this issue elsewhere, absence of an HTML5 frameset spec is
> being touted as nailing the case for "framesets are evil, get rid of them".
> Obviously, absence of an HTML5 frameset spec enables that agenda. I do need
> to bother.
"elsewhere"? And why should that matter *here*?
The reasons why there is no HTML5 frameset spec have been clearly
stated several times on this discussion. If these reasons are being
miss-represent elsewhere, this isn't something that should, in
principle, bother the spec.
If the issue arose from some text of the spec not being clear enough,
then that'd be a spec issue, and could be relevant here. If you think
this is the case, my best advise is to send a proposal to add the
appropriate clarification somewhere in the spec. For it to be taken
seriously by the editor, I strongly recommend that you send spec-ready
quality text, make clear where should it be added (or what and where
should it replace), and, most importantly, provide examples of the
issue (for example, sites using the absence of a HTML5 frameset
doctype as an argument for the "framesets are bad" idea).

> Can I take your non-response to "You are not the first to claim that tables
> & iframes can meet this spec ... if it does I ought to have been able to
> find a working instance in the past six years or so, don't you think?" as
> agreement that there are serious reasons for preferring framesets to tables
> & iframes for this problem?
No, you can't. I simply overlooked that in my previous reply.
In any case, I didn't claim that + alone would meet
your requirements. I clearly stated that such approach would miss the
resizing requirement, and that it could be hacked through scripting.
 is enough to display frames, wherever you want on a document
(after all, that's what it is for).  gives you the layout tools
provided by  (such as the @cols and @rows attributes, and
nesting). A quick Google search [1] yields several examples of making
a table resizable.


I'm going to make a last effort to push this discussion to some degree
of usefulness.
AFAIC, we both agree that  is currently the best solution
for the use case you provided.
It seems that  covers most requirements. Is there any
requirement not covered by this solution?
 is not being removed from HTML. It's just not being updated
because there wa

Re: [whatwg] framesets

2009-10-11 Thread David Workman

Oops, only sent this to one recipient earlier.

2009/10/11 David Workman 

> Peter,
>
> From reading this discussion, I think you've slightly missed a salient
> point with regards to the current state of play with frames.
>
> Frames aren't in HTML 4.01 Strict, they were moved into their own standard,
> HTML4.01 Frameset. With HTML5, they aren't being removed, they simply aren't
> being updated. With no updates, their version, standard and DTD are going to
> remain the same, namely HTML4.01 Frameset.
>
> What you are actually arguing for therefore is the inclusion of all the
> elements of HTML4.01 Frameset into HTML5 Strict and HTML5 Transitional. As
> you seem to have no objection to how frames are handled in 4.01 it therefore
> seems odd that you are arguing for a radical change for them in HTML5.
>
> As for people saying they are being 'removed' from HTML5, I see that as
> merely a colloquial use of the term and what they actually mean is 'With the
> HTML5 specification process, we aren't going to update the Frameset standard
> and as such this standard has been removed from our scope'. I think you can
> see why saying 'removed' is so much easier ;)
>
> David Workman
>
> 2009/10/11 Peter Brawley 
>
>  Edouard,
>>
>> >Use case: displaying tree-based content (editable or not). (Note: I'm
>> >omitting the database aspect because it only matters on the server
>> >side: once on the client, the page doesn't care whether the data comes
>> >from/goes to a database, a collection of files, or anywhere else).
>>
>> I'm afraid that empties meaning from the use case, whose requirements
>> significant to this discussion arise from the database context:
>> (i) the required page is a database maintenance webapp,
>> (ii) the data it maintains is in the form of a tree, and
>> (iii) the objects of database maintenance (rows in the database tables
>> which instantiate the tree) usually should not be bookmarkable for the same
>> reason other database webapps (eg phpMyAdmin) do not bookmark database
>> data---a bookmark belongs to a browser, but a row of database table data
>> belongs not to a browser but to users who may CRUD it, *and access to
>> such objects must not be shortcutted*. That is, database maintenance in a
>> webapp depends at least partly on protecting data from some popular web
>> mechanisms. If that offends HTML purists, or if this use case conflicts with
>> an "original" idea about the web, so be it. For this context, HTML is just a
>> device for getting useful things done on the web while enforcing the rules
>> of database maintenance.
>>
>> >First, let's look at what the currently existing solutions are: I may
>> >be missing some, but I hope the range is descriptive enough:
>> >A) +: This meets requirements 1, 2, and 5 out of the
>> >box. Requirement 3 could be achieved with some javascript.
>> >B) CSS position:fixed + overflow:auto: Again, this meets requirements
>> >1, 2, and 5. Requirement 3 would also be achievable with a bit of
>> >scripting.
>> >C) Insane s + CSS + Scripting: This essentially meets all
>> >requirements (maybe excluding 4, depending on what the actual
>> >requirement is); although at a high development cost. (This would be
>> >the "MSDN style" approach.)
>> >D) HTML4 Frameset + HTML5 documents for frame contents: this meets
>> >requirements 1, 2, 3, and 5 out of the box, it's an almost trivial
>> >upgrade from any HTML4 web-app that takes a similar approach, and is
>> >relatively easy to implement.
>>
>> Seems to me many developers would regard B & C as hacks. At they very
>> least they'd be more awkward than framesets. I think I've already touched on
>> why the MSDN approach is undesirable. You are not the first to claim that A
>> (tables & iframes) can meet this spec. I'm not an HTML expert (which
>> apparently frustrates you) but if A meets the spec, I ought to have been
>> able to find a working instance in the past six years or so, don't you
>> think? Or do you claim it's *entirely fortuitous* that the only publicly
>> well known solutions for this spec use framesets?
>>
>> Re D), reasons for opposing removing framesets from HTML5 include: (i)
>> removal of a feature from a standard is often followed by further
>> degradation of support for it, which would undermine the functionality I
>> want HTML to support since framesets are commonly used, for good reasons, to
>> meet this use case, (ii) there could be HTML5 features one would want to
>> combine with framesets.
>>
>> Apropos the strange claims made here that removal of framesets should make
>> no difference to present or future frameset use: *if removal makes no
>> difference whatever, there is no rationale for removing them*.
>>
>> PB
>> -
>>
>> Eduard Pascual wrote:
>>
>> On Sat, Oct 10, 2009 at 6:12 AM, Peter Brawley  
>>  wrote:
>>
>>
>>  [lots...]
>>
>>
>>  Now, your last mail does describe the use-cases and their presumed
>> requirements. Your wording is maybe a bit messy, but you have at least
>> provided somethin

Re: [whatwg] framesets

2009-10-11 Thread Peter Brawley

Edouard,

>1) Your example with phpMyAdmin (PMA for short) is slightly wrong (and
>I'm speaking with several years of experience using it): I just did a
>bit of testing on my PMA 2.11.9.4 installation and bookmarking works
>fine down to a reasonable degree: of course, I can't bookmark a "row"
>itself (wouldn't make much sense, as rows can appear and disappear
>quite often), but I can bookmark most (almost all) of the "screens" of
>PMA, such as "list of tables in db X", "insert new row on table Y",

In a treeview, node=row, detail page=row. It must be possible to block 
bookmarking of individual rows and columns.

>3) Finally, this may sound a bit too theoretical, but I think it's
>worth pointing out: your idea of breaking bookmarking and similar
>features, as described on your last mail, is not an actual
>requirement: it seems to be your try at addressing the security
>requirement.

With all due respect, the client decides what the requirements are & 
aren't. This use case includes the requirement that the user be able to 
drop into and out of tree maintenance as if it were a black box. There 
are three main reasons for that: non-tree webnav convenience, 
restriction of node access mechanisms to those implemented by the 
webapp, avoidance of shortcut webnav access to specific rows.

>Finally, you don't need to bother too much about how the HTML5 spec
>will impact on browser support for deprecated and non-updated
>features: it simply won't. It's a matter of offer and demand: as long
>as there are  or  tags out there, browsers will be
>able to handle them, regardless of what the spec may say (currently,
>the spec just tries to make the different UAs agree on how to handle
>these and worse things).

In discussion of this issue elsewhere, absence of an HTML5 frameset spec 
is being touted as nailing the case for "framesets are evil, get rid of 
them". Obviously, absence of an HTML5 frameset spec enables that agenda. 
I do need to bother.

Can I take your non-response to "You are not the first to claim that 
tables & iframes can meet this spec ... if it does I ought to have been 
able to find a working instance in the past six years or so, don't you 
think?" as agreement that there are serious reasons for preferring 
framesets to tables & iframes for this problem?

PB

-

Eduard Pascual wrote:

On Sun, Oct 11, 2009 at 3:12 AM, Peter Brawley  wrote:

Edouard,

Use case: displaying tree-based content (editable or not). (Note: I'm
omitting the database aspect because it only matters on the server
side: once on the client, the page doesn't care whether the data comes
from/goes to a database, a collection of files, or anywhere else).

I'm afraid that empties meaning from the use case, whose requirements
significant to this discussion arise from the database context:
(i) the required page is a database maintenance webapp,

Still, I think that matters on the server, but how much does it matter
on the client? How does this affect the requirements for the
client-side part of the application? Even if it really matters, which
requirements for the use-case will be derived from this aspect?

(ii) the data it maintains is in the form of a tree, and

I think that was quite covered by the description "displaying
tree-based content (editable or not)".

(iii) the objects of database maintenance (rows in the database tables which
instantiate the tree) usually should not be bookmarkable for the same reason
other database webapps (eg phpMyAdmin) do not bookmark database data---a
bookmark belongs to a browser, but a row of database table data belongs not
to a browser but to users who may CRUD it, and access to such objects must
not be shortcutted. That is, database maintenance in a webapp depends at
least partly on protecting data from some popular web mechanisms. If that
offends HTML purists, or if this use case conflicts with an "original" idea
about the web, so be it. For this context, HTML is just a device for getting
useful things done on the web while enforcing the rules of database
maintenance.

There are too many assumptions here, and I think they should be
addressed separately:
1) Your example with phpMyAdmin (PMA for short) is slightly wrong (and
I'm speaking with several years of experience using it): I just did a
bit of testing on my PMA 2.11.9.4 installation and bookmarking works
fine down to a reasonable degree: of course, I can't bookmark a "row"
itself (wouldn't make much sense, as rows can appear and disappear
quite often), but I can bookmark most (almost all) of the "screens" of
PMA, such as "list of tables in db X", "insert new row on table Y",
"table Z's view for rows N to M", and so on. I heavily use these
features to manage my online databases (for example, I have a shortcut
to add contents to my main site by inserting the rows with the new
contents on the DB), so I consider this a quite desirable feature.
2) This is quite serious: you seem to be arguing that book

Re: [whatwg] framesets

2009-10-11 Thread Eduard Pascual

On Sun, Oct 11, 2009 at 3:12 AM, Peter Brawley  wrote:
> Edouard,
>
>>Use case: displaying tree-based content (editable or not). (Note: I'm
>>omitting the database aspect because it only matters on the server
>>side: once on the client, the page doesn't care whether the data comes
>>from/goes to a database, a collection of files, or anywhere else).
>
> I'm afraid that empties meaning from the use case, whose requirements
> significant to this discussion arise from the database context:
> (i) the required page is a database maintenance webapp,
Still, I think that matters on the server, but how much does it matter
on the client? How does this affect the requirements for the
client-side part of the application? Even if it really matters, which
requirements for the use-case will be derived from this aspect?

> (ii) the data it maintains is in the form of a tree, and
I think that was quite covered by the description "displaying
tree-based content (editable or not)".

> (iii) the objects of database maintenance (rows in the database tables which
> instantiate the tree) usually should not be bookmarkable for the same reason
> other database webapps (eg phpMyAdmin) do not bookmark database data---a
> bookmark belongs to a browser, but a row of database table data belongs not
> to a browser but to users who may CRUD it, and access to such objects must
> not be shortcutted. That is, database maintenance in a webapp depends at
> least partly on protecting data from some popular web mechanisms. If that
> offends HTML purists, or if this use case conflicts with an "original" idea
> about the web, so be it. For this context, HTML is just a device for getting
> useful things done on the web while enforcing the rules of database
> maintenance.
There are too many assumptions here, and I think they should be
addressed separately:
1) Your example with phpMyAdmin (PMA for short) is slightly wrong (and
I'm speaking with several years of experience using it): I just did a
bit of testing on my PMA 2.11.9.4 installation and bookmarking works
fine down to a reasonable degree: of course, I can't bookmark a "row"
itself (wouldn't make much sense, as rows can appear and disappear
quite often), but I can bookmark most (almost all) of the "screens" of
PMA, such as "list of tables in db X", "insert new row on table Y",
"table Z's view for rows N to M", and so on. I heavily use these
features to manage my online databases (for example, I have a shortcut
to add contents to my main site by inserting the rows with the new
contents on the DB), so I consider this a quite desirable feature.
2) This is quite serious: you seem to be arguing that bookmarking and
other features should break in order to protect data. This fails in
both directions:
a) Breaking bookmarking and other features doesn't really protect the data, and
b) protecting the data doesn't require any of these features to break.
Let me go back to the PMA examples: if, after closing session on my
browser, I reopen the browser and try to reach my "content addition
bookmark", the PMA scripts will ask me for my user and password again:
if I enter them correctly, I'll be in and will be able to go straight
away into inserting my contents; otherwise I'd simply get an error
message.
I understand that security and access control is a serious concern,
but you need to realize that this approach to it is flawed: if you
want content to be actually protected, then you must make sure, from
the server scripts, that the content is *never* sent to an
unauthorized client. If it's sent, then there is no point in trying to
hide it on the page: a malicious user can reach it from the page
source, and (depending on how your application is designed) may even
be able to trigger an update.
You may think of it this way: on the client side, the client has the
power to override anything you try (view source, grease-monkey
scripts, customized browsers... there are plenty of ways): the client
has control over what runs on the client's machine. It's only on the
server side where you have full control; and thus anything that relies
on such control (such as managing permissions) should be handled
there.
3) Finally, this may sound a bit too theoretical, but I think it's
worth pointing out: your idea of breaking bookmarking and similar
features, as described on your last mail, is not an actual
requirement: it seems to be your try at addressing the security
requirement. For example, would you be happy with a solution that
allowed these features (to some reasonable degree, maybe comparable to
PMA) if it fulfilled all of the other requirements (including being
100% secure)?

>>First, let's look at what the currently existing solutions are: I may
>>be missing some, but I hope the range is descriptive enough:
>>A) +: This meets requirements 1, 2, and 5 out of the
>>box. Requirement 3 could be achieved with some javascript.
>>B) CSS position:fixed + overflow:auto: Again, this meets requirements
>>1, 2, and 5. Requirement 3

Re: [whatwg] framesets

2009-10-10 Thread Peter Brawley


Edouard,


Use case: displaying tree-based content (editable or not). (Note: I'm
omitting the database aspect because it only matters on the server
side: once on the client, the page doesn't care whether the data comes
from/goes to a database, a collection of files, or anywhere else).


I'm afraid that empties meaning from the use case, whose requirements 
significant to this discussion arise from the database context:

(i) the required page is a database maintenance webapp,
(ii) the data it maintains is in the form of a tree, and
(iii) the objects of database maintenance (rows in the database tables 
which instantiate the tree) usually should not be bookmarkable for the 
same reason other database webapps (eg phpMyAdmin) do not bookmark 
database data---a bookmark belongs to a browser, but a row of database 
table data belongs not to a browser but to users who may CRUD it, /and 
access to such objects must not be shortcutted/. That is, database 
maintenance in a webapp depends at least partly on protecting data from 
some popular web mechanisms. If that offends HTML purists, or if this 
use case conflicts with an "original" idea about the web, so be it. For 
this context, HTML is just a device for getting useful things done on 
the web while enforcing the rules of database maintenance.



First, let's look at what the currently existing solutions are: I may
be missing some, but I hope the range is descriptive enough:
A) +: This meets requirements 1, 2, and 5 out of the
box. Requirement 3 could be achieved with some javascript.
B) CSS position:fixed + overflow:auto: Again, this meets requirements
1, 2, and 5. Requirement 3 would also be achievable with a bit of
scripting.
C) Insane s + CSS + Scripting: This essentially meets all
requirements (maybe excluding 4, depending on what the actual
requirement is); although at a high development cost. (This would be
the "MSDN style" approach.)
D) HTML4 Frameset + HTML5 documents for frame contents: this meets
requirements 1, 2, 3, and 5 out of the box, it's an almost trivial
upgrade from any HTML4 web-app that takes a similar approach, and is
relatively easy to implement.


Seems to me many developers would regard B & C as hacks. At they very 
least they'd be more awkward than framesets. I think I've already 
touched on why the MSDN approach is undesirable. You are not the first 
to claim that A (tables & iframes) can meet this spec. I'm not an HTML 
expert (which apparently frustrates you) but if A meets the spec, I 
ought to have been able to find a working instance in the past six years 
or so, don't you think? Or do you claim it's /entirely fortuitous/ that 
the only publicly well known solutions for this spec use framesets?


Re D), reasons for opposing removing framesets from HTML5 include: (i) 
removal of a feature from a standard is often followed by further 
degradation of support for it, which would undermine the functionality I 
want HTML to support since framesets are commonly used, for good 
reasons, to meet this use case, (ii) there could be HTML5 features one 
would want to combine with framesets.


Apropos the strange claims made here that removal of framesets should 
make no difference to present or future frameset use: /if removal makes 
no difference whatever, there is no rationale for removing them/.


PB
-

Eduard Pascual wrote:

On Sat, Oct 10, 2009 at 6:12 AM, Peter Brawley  wrote:
  

[lots...]



Now, your last mail does describe the use-cases and their presumed
requirements. Your wording is maybe a bit messy, but you have at least
provided something worth discussing.
Just to make sure I (and others) are understanding your proposal as
intended, I'll try to paraphrase it in a more structured way (please,
if I got something wrong, just let me know):

Use case: displaying tree-based content (editable or not). (Note: I'm
omitting the database aspect because it only matters on the server
side: once on the client, the page doesn't care whether the data comes
from/goes to a database, a collection of files, or anywhere else).
Requirements:
1) The display will use multiple subwindows, such as "header",
"tree-view", and "content" (the names are arbitrary, hope they are
descriptive and concise).
2) The subwindows (or some of them) need to be independently scrollable.
3) The subwindows must be resizable.
4) The tree structure being displayed may be protected through some
permission mechanism, so each user only gets to see or interact with
the nodes such user has permissions for.
5) The "back button" and "bookmark" features shouldn't work.

So far, so good. Just if you had gone a bit further...
That's a use-case with a series of requirements. This is a good
beginning, but let's go to the next steps.
Requirement justification: you haven't provided any (it's the
requirements, not the use-case itself, what needs to be justified; a
use-case is inherently justified by the real-world needs it
addresses).
For requirements 1 to 3, I can assume as an im

Re: [whatwg] framesets

2009-10-10 Thread Peter Brawley


Tali,

Not sure whom you're asking, but my take is yes there's no good solution 
but the frameset is the least worst I've found so far.


PB

-

tali garsiel wrote:
 	<6ea53250910101207l3c190722he405b983fc7ba...@mail.gmail.com> 



 


 <6ea53250910101551x5239027end5fc1b52cea81...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0



What I'm saying is based on my experience. I'v been involved in developement of 
large and complex web application for the last 9 years.

I know this discussion is getting too long but I believe it's because it 
touches a real problem.

Lets try to see where we disagree.

1. Tabs and tree menu navigation is very common in web applications.
Do you agree with that assumption?

Possible solutions for creating such navigation are:

1. Using one page + server side includes to repaint the navigation every time.
Not good.From my experience it burdens the server (it's not just images - its 
reading the XML that describes the tabs , calculating tree permissions , 
getting the whole tree data from the database etc) and causes a noticeable 
flicker.

2. Using frames - not good from the reasons you pointed out

3. Using iframes - not good from the same reasons

4. Using ajax - not good.From my experience browsers know how to load documents 
and don't react well in a situation where there is one document and every 
screen is built by updating the DOM of this document.I think the tests browser 
do do not include such cases and its not how they are meant to act.

So - for an extremely common use case there is no solution at all.

Again , please specify where you disagree.

Solution - I don't have a detailed solution but I think that the applications 
outer structure should be described by special tags which will behave well with 
bookmarking and the back button.
In outer structure I mean the part of the layout that consistently appears in 
each screen.


Tali
 





  

From: herenva...@gmail.com
Date: Sun, 11 Oct 2009 00:51:53 +0200
To: t_gars...@hotmail.com
CC: p...@artfulsoftware.com; t.bro...@gmail.com; bzbar...@mit.edu; 
wha...@whatwg.org
Subject: Re: [whatwg] framesets

On Sun, Oct 11, 2009 at 12:15 AM, tali garsiel  wrote:


I agree with Peter that this type of document navigation is an extremely common 
use case.
I think the use case includes navigation that loads only parts of the page, 
leaving the other parts static.

Almost all web applications I know have tabs on top and a tree on the left.

The idea is not repainting the tabs/tree etc on every click to keep a good user 
experience.

On the old days frames were used, then a tables + iframes.

Then iframes where considered bad design and I think most applications use divs 
+ css + Ajax.
  

Peter's case is quite legitimate; I just asked for him to properly
detail it so it can be properly discussed.

Your reference to the "old days", however, scares me a bit: on the
"old days" there weren't many web applications, only web pages. If you
are trying to argue for sites (made of pages or documents) that use
s to keep the menus and headers static, I must stronly
oppose that: while neglecting the "back button", "bookmarking" and
"deep-linking" features inherent to the web may be acceptable for some
specific applications, this is absolutely a bad idea for "classic"
pages: these elements do not take that much to load (and, if they use
images, the browser will have them cached anyway), and all other
advantages of using frames in this scenario (such as maintaining a
single instance of the menu) are far better handled through
server-side solutions such as "includes". Being unable to deep-link to
(or bookmark) a specific page on a site is a serious drawback; hence
any site that considers breaking such capabilities must accurately
weight the cost of the drawback against the value of the benefits it
expects to achieve from it.
If you have specific use-cases for Peter's proposal, you're welcome to
bring them forward... oh, wait... what's Peter's proposal?



I think its important that the W3C specification should provide a good solution 
for this common case.
  

You know, solutions don't come out of thin air: they are proposed by
contributors to the lists like you, or me, or anyone else here. If you
know the cases you want to have addressed, then I strongly encourage
you to suggest a solution. The same advise I gave Peter applies: make
sure to describe the use-cases you are addressing, detailing the
requirements (and justifying them when they aren't 100% obvious),
showing where current solutions fail, and showing that your proposal
meets all the requirements.

Honestly, I don't think that this process is ideal, but it's th

Re: [whatwg] framesets

2009-10-10 Thread tali garsiel


<6ea53250910101207l3c190722he405b983fc7ba...@mail.gmail.com> 


 

 <6ea53250910101551x5239027end5fc1b52cea81...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


Here is my suggestion - adding a "type" and "navigation-state" attributes to 
frameset in order for bookmarking , deep linking and back button to work.

Something like:

  //here I put my tabs
  //here I put the menu
     //the content



The browser will keep a match between the navigation-state of the navigation 
frames and the URL of the content frame.

use case:
The user clicks a tab - the "navigation-state" will change using JavaScript  
from "1" to "2, the "content" frame is reloaded.
The user clicks the "bookmark" button.
The browser puts in the bookmark storage the new content URL + the new state.

When the bookmark is invoked the browser loads tabs and menu frames and exposes 
the navigation state to them.It also loads the content with the new URL.
The tabs frame uses the state information to display the correct tab using 
JavaScript.
Something like history.navigationState.

The tab and menu frames might be in different navigation states.
There can be a combination of tabs in state "1" , tree in state "2" , content 
URL is x.
The browser will remember the combination when bookmarking.

Tali



> From: herenva...@gmail.com
> Date: Sun, 11 Oct 2009 00:51:53 +0200
> To: t_gars...@hotmail.com
> CC: p...@artfulsoftware.com; t.bro...@gmail.com; bzbar...@mit.edu; 
> wha...@whatwg.org
> Subject: Re: [whatwg] framesets
>
> On Sun, Oct 11, 2009 at 12:15 AM, tali garsiel  wrote:
>> I agree with Peter that this type of document navigation is an extremely 
>> common use case.
>> I think the use case includes navigation that loads only parts of the page, 
>> leaving the other parts static.
>>
>> Almost all web applications I know have tabs on top and a tree on the left.
>>
>> The idea is not repainting the tabs/tree etc on every click to keep a good 
>> user experience.
>>
>> On the old days frames were used, then a tables + iframes.
>>
>> Then iframes where considered bad design and I think most applications use 
>> divs + css + Ajax.
> Peter's case is quite legitimate; I just asked for him to properly
> detail it so it can be properly discussed.
>
> Your reference to the "old days", however, scares me a bit: on the
> "old days" there weren't many web applications, only web pages. If you
> are trying to argue for sites (made of pages or documents) that use
> s to keep the menus and headers static, I must stronly
> oppose that: while neglecting the "back button", "bookmarking" and
> "deep-linking" features inherent to the web may be acceptable for some
> specific applications, this is absolutely a bad idea for "classic"
> pages: these elements do not take that much to load (and, if they use
> images, the browser will have them cached anyway), and all other
> advantages of using frames in this scenario (such as maintaining a
> single instance of the menu) are far better handled through
> server-side solutions such as "includes". Being unable to deep-link to
> (or bookmark) a specific page on a site is a serious drawback; hence
> any site that considers breaking such capabilities must accurately
> weight the cost of the drawback against the value of the benefits it
> expects to achieve from it.
> If you have specific use-cases for Peter's proposal, you're welcome to
> bring them forward... oh, wait... what's Peter's proposal?
>
>> I think its important that the W3C specification should provide a good 
>> solution for this common case.
> You know, solutions don't come out of thin air: they are proposed by
> contributors to the lists like you, or me, or anyone else here. If you
> know the cases you want to have addressed, then I strongly encourage
> you to suggest a solution. The same advise I gave Peter applies: make
> sure to describe the use-cases you are addressing, detailing the
> requirements (and justifying them when they aren't 100% obvious),
> showing where current solutions fail, and showing that your proposal
> meets all the requirements.
>
> Honestly, I don't think that this process is ideal, but it's the way
> things are normally done here, and I can't think of a better process
> (otherwise I'd bring it forward). Some discussion on the abstract can
> be useful, but at the end of the day, only solutions that address
> use-cases and meet requirements make it into th

Re: [whatwg] framesets

2009-10-10 Thread tali garsiel

<6ea53250910101207l3c190722he405b983fc7ba...@mail.gmail.com> 

 <6ea53250910101551x5239027end5fc1b52cea81...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0

What I'm saying is based on my experience. I'v been involved in developement of 
large and complex web application for the last 9 years.

I know this discussion is getting too long but I believe it's because it 
touches a real problem.

Lets try to see where we disagree.

1. Tabs and tree menu navigation is very common in web applications.
Do you agree with that assumption?

Possible solutions for creating such navigation are:

1. Using one page + server side includes to repaint the navigation every time.
Not good.From my experience it burdens the server (it's not just images - its 
reading the XML that describes the tabs , calculating tree permissions , 
getting the whole tree data from the database etc) and causes a noticeable 
flicker.

2. Using frames - not good from the reasons you pointed out

3. Using iframes - not good from the same reasons

4. Using ajax - not good.From my experience browsers know how to load documents 
and don't react well in a situation where there is one document and every 
screen is built by updating the DOM of this document.I think the tests browser 
do do not include such cases and its not how they are meant to act.

So - for an extremely common use case there is no solution at all.

Again , please specify where you disagree.

Solution - I don't have a detailed solution but I think that the applications 
outer structure should be described by special tags which will behave well with 
bookmarking and the back button.
In outer structure I mean the part of the layout that consistently appears in 
each screen.

Tali

> From: herenva...@gmail.com
> Date: Sun, 11 Oct 2009 00:51:53 +0200
> To: t_gars...@hotmail.com
> CC: p...@artfulsoftware.com; t.bro...@gmail.com; bzbar...@mit.edu; 
> wha...@whatwg.org
> Subject: Re: [whatwg] framesets
>
> On Sun, Oct 11, 2009 at 12:15 AM, tali garsiel  wrote:
>> I agree with Peter that this type of document navigation is an extremely 
>> common use case.
>> I think the use case includes navigation that loads only parts of the page, 
>> leaving the other parts static.
>>
>> Almost all web applications I know have tabs on top and a tree on the left.
>>
>> The idea is not repainting the tabs/tree etc on every click to keep a good 
>> user experience.
>>
>> On the old days frames were used, then a tables + iframes.
>>
>> Then iframes where considered bad design and I think most applications use 
>> divs + css + Ajax.
> Peter's case is quite legitimate; I just asked for him to properly
> detail it so it can be properly discussed.
>
> Your reference to the "old days", however, scares me a bit: on the
> "old days" there weren't many web applications, only web pages. If you
> are trying to argue for sites (made of pages or documents) that use
> s to keep the menus and headers static, I must stronly
> oppose that: while neglecting the "back button", "bookmarking" and
> "deep-linking" features inherent to the web may be acceptable for some
> specific applications, this is absolutely a bad idea for "classic"
> pages: these elements do not take that much to load (and, if they use
> images, the browser will have them cached anyway), and all other
> advantages of using frames in this scenario (such as maintaining a
> single instance of the menu) are far better handled through
> server-side solutions such as "includes". Being unable to deep-link to
> (or bookmark) a specific page on a site is a serious drawback; hence
> any site that considers breaking such capabilities must accurately
> weight the cost of the drawback against the value of the benefits it
> expects to achieve from it.
> If you have specific use-cases for Peter's proposal, you're welcome to
> bring them forward... oh, wait... what's Peter's proposal?
>
>> I think its important that the W3C specification should provide a good 
>> solution for this common case.
> You know, solutions don't come out of thin air: they are proposed by
> contributors to the lists like you, or me, or anyone else here. If you
> know the cases you want to have addressed, then I strongly encourage
> you to suggest a solution. The same advise I gave Peter applies: make
> sure to describe the use-cases you are addressing, detailing the
> requirements (and justifying them when they aren't 100% obvious),
> showing where current solutions fail, and showing that your proposal

Re: [whatwg] framesets

2009-10-10 Thread Eduard Pascual

On Sun, Oct 11, 2009 at 12:15 AM, tali garsiel  wrote:
> I agree with Peter that this type of document navigation is an extremely 
> common use case.
> I think the use case includes navigation that loads only parts of the page, 
> leaving the other parts static.
>
> Almost all web applications I know have tabs on top and a tree on the left.
>
> The idea is not repainting the tabs/tree etc on every click to keep a good 
> user experience.
>
> On the old days frames were used, then a tables + iframes.
>
> Then iframes where considered bad design and I think most applications use 
> divs + css + Ajax.
Peter's case is quite legitimate; I just asked for him to properly
detail it so it can be properly discussed.

Your reference to the "old days", however, scares me a bit: on the
"old days" there weren't many web applications, only web pages. If you
are trying to argue for sites (made of pages or documents) that use
s to keep the menus and headers static, I must stronly
oppose that: while neglecting the "back button", "bookmarking" and
"deep-linking" features inherent to the web may be acceptable for some
specific applications, this is absolutely a bad idea for "classic"
pages: these elements do not take that much to load (and, if they use
images, the browser will have them cached anyway), and all other
advantages of using frames in this scenario (such as maintaining a
single instance of the menu) are far better handled through
server-side solutions such as "includes". Being unable to deep-link to
(or bookmark) a specific page on a site is a serious drawback; hence
any site that considers breaking such capabilities must accurately
weight the cost of the drawback against the value of the benefits it
expects to achieve from it.
If you have specific use-cases for Peter's proposal, you're welcome to
bring them forward... oh, wait... what's Peter's proposal?

> I think its important that the W3C specification should provide a good 
> solution for this common case.
You know, solutions don't come out of thin air: they are proposed by
contributors to the lists like you, or me, or anyone else here. If you
know the cases you want to have addressed, then I strongly encourage
you to suggest a solution. The same advise I gave Peter applies: make
sure to describe the use-cases you are addressing, detailing the
requirements (and justifying them when they aren't 100% obvious),
showing where current solutions fail, and showing that your proposal
meets all the requirements.

Honestly, I don't think that this process is ideal, but it's the way
things are normally done here, and I can't think of a better process
(otherwise I'd bring it forward). Some discussion on the abstract can
be useful, but at the end of the day, only solutions that address
use-cases and meet requirements make it into the spec.

Finally, let me insist on a small detail that seems to go unnoticed
regardless of how many times it has been repeated in the last hours:
HTML5 updates/replaces the Transitional and Strict doctypes of HTML4.
HTML4 Frameset isn't being updated as of now, and it stays valid,
legitimate, and current. Using a HTML4 Frameset master page that shows
HTML5 documents on its frames is valid and conformant. In addition,
this seems to address all the use-cases that have been put forward (at
least, it addresses all the ones HTML4 Frameset + HTML4 inside frames
could address).
What is being asked for? What do you (and/or Peter) want to be changed
on the spec, and why? If nobody answers this, there is very little
hope this discussion will go anywhere.

Regards,
Eduard Pascual

Re: [whatwg] framesets

2009-10-10 Thread tali garsiel


<7c2a12e20910091119j2e527fc7x3e50e668342a9...@mail.gmail.com> 

<4acf873d.6000...@artfulsoftware.com> <4acf8b51.80...@mit.edu> 

<4acf9e08.1020...@artfulsoftware.com>

 

<4acfcb99.1040...@artfulsoftware.com>

<6ea53250910091718md017d92xe32e244fca334...@mail.gmail.com> 

<4ad009b2.9040...@artfulsoftware.com>
 

 <6ea53250910101207l3c190722he405b983fc7ba...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0



I agree with Peter that this type of document navigation is an extremely common 
use case.
I think the use case includes navigation that loads only parts of the page, 
leaving the other parts static.

Almost all web applications I know have tabs on top and a tree on the left.

The idea is not repainting the tabs/tree etc on every click to keep a good user 
experience.

On the old days frames were used, then a tables + iframes.

Then iframes where considered bad design and I think most applications use divs 
+ css + Ajax.

In my experience this is not good either and causes serious performance issues.
I think its called "single page design" where the browser is never told to 
unload a document and reload another but just to keep updating the DOM using 
Ajax with huge chunks of HTML.

I think its important that the W3C specification should provide a good solution 
for this common case.


Regards, 
Tali


> From: herenva...@gmail.com
> Date: Sat, 10 Oct 2009 21:07:42 +0200
> To: p...@artfulsoftware.com
> CC: wha...@whatwg.org; t.bro...@gmail.com; bzbar...@mit.edu
> Subject: Re: [whatwg] framesets
>
> On Sat, Oct 10, 2009 at 6:12 AM, Peter Brawley  wrote:
>> [lots...]
>
> Now, your last mail does describe the use-cases and their presumed
> requirements. Your wording is maybe a bit messy, but you have at least
> provided something worth discussing.
> Just to make sure I (and others) are understanding your proposal as
> intended, I'll try to paraphrase it in a more structured way (please,
> if I got something wrong, just let me know):
>
> Use case: displaying tree-based content (editable or not). (Note: I'm
> omitting the database aspect because it only matters on the server
> side: once on the client, the page doesn't care whether the data comes
> from/goes to a database, a collection of files, or anywhere else).
> Requirements:
> 1) The display will use multiple subwindows, such as "header",
> "tree-view", and "content" (the names are arbitrary, hope they are
> descriptive and concise).
> 2) The subwindows (or some of them) need to be independently scrollable.
> 3) The subwindows must be resizable.
> 4) The tree structure being displayed may be protected through some
> permission mechanism, so each user only gets to see or interact with
> the nodes such user has permissions for.
> 5) The "back button" and "bookmark" features shouldn't work.
>
> So far, so good. Just if you had gone a bit further...
> That's a use-case with a series of requirements. This is a good
> beginning, but let's go to the next steps.
> Requirement justification: you haven't provided any (it's the
> requirements, not the use-case itself, what needs to be justified; a
> use-case is inherently justified by the real-world needs it
> addresses).
> For requirements 1 to 3, I can assume as an implicit justification
> something like "this is the behavior every user would expect" or
> anything like that, so let's move forward.
> For requirement 4, things are a bit weird: should authentication be
> handled on the server or on the client side? It seems that it has to
> be handled on the server side, so the nodes a user is not allowed to
> see should never be sent to the client (otherwise, the user could look
> at the source, hack through grease-monkey scripts, or override the
> permission system in many ways). If it's handled by the server, then
> it isn't relevant to HTML: HTML is a client-side language. If there is
> some need to handle (part of) the authentication issue from the
> client, you should provide more details and justify such need;
> otherwise the requirement can just be omitted as it wouldn't be
> relevant.
> Requirement 5 does need some justification. In my opinion, there is no
> need on your use case for these features (back button and bookmarks)
> to work, but is there any real need for them to break? If there is,
> please justify it; if there isn't, then that's not a requirement (it
> would just be the absence of a requirement for these features to
> work). Not needing them to work is *not* the sa

Re: [whatwg] framesets

2009-10-10 Thread Eduard Pascual

On Sat, Oct 10, 2009 at 6:12 AM, Peter Brawley  wrote:
> [lots...]

Now, your last mail does describe the use-cases and their presumed
requirements. Your wording is maybe a bit messy, but you have at least
provided something worth discussing.
Just to make sure I (and others) are understanding your proposal as
intended, I'll try to paraphrase it in a more structured way (please,
if I got something wrong, just let me know):

Use case: displaying tree-based content (editable or not). (Note: I'm
omitting the database aspect because it only matters on the server
side: once on the client, the page doesn't care whether the data comes
from/goes to a database, a collection of files, or anywhere else).
Requirements:
1) The display will use multiple subwindows, such as "header",
"tree-view", and "content" (the names are arbitrary, hope they are
descriptive and concise).
2) The subwindows (or some of them) need to be independently scrollable.
3) The subwindows must be resizable.
4) The tree structure being displayed may be protected through some
permission mechanism, so each user only gets to see or interact with
the nodes such user has permissions for.
5) The "back button" and "bookmark" features shouldn't work.

So far, so good. Just if you had gone a bit further...
That's a use-case with a series of requirements. This is a good
beginning, but let's go to the next steps.
Requirement justification: you haven't provided any (it's the
requirements, not the use-case itself, what needs to be justified; a
use-case is inherently justified by the real-world needs it
addresses).
For requirements 1 to 3, I can assume as an implicit justification
something like "this is the behavior every user would expect" or
anything like that, so let's move forward.
For requirement 4, things are a bit weird: should authentication be
handled on the server or on the client side? It seems that it has to
be handled on the server side, so the nodes a user is not allowed to
see should never be sent to the client (otherwise, the user could look
at the source, hack through grease-monkey scripts, or override the
permission system in many ways). If it's handled by the server, then
it isn't relevant to HTML: HTML is a client-side language. If there is
some need to handle (part of) the authentication issue from the
client, you should provide more details and justify such need;
otherwise the requirement can just be omitted as it wouldn't be
relevant.
Requirement 5 does need some justification. In my opinion, there is no
need on your use case for these features (back button and bookmarks)
to work, but is there any real need for them to break? If there is,
please justify it; if there isn't, then that's not a requirement (it
would just be the absence of a requirement for these features to
work). Not needing them to work is *not* the same as needing them to
break.

Now, leaving aside the issues with the last two requirements, we can
move forward. The next step would be to see which requirements are met
by currently existing solutions, and which aren't. I will be ignoring
for now Requirement 4 because it's unclear what the actual requirement
would be.
First, let's look at what the currently existing solutions are: I may
be missing some, but I hope the range is descriptive enough:
A) +: This meets requirements 1, 2, and 5 out of the
box. Requirement 3 could be achieved with some javascript.
B) CSS position:fixed + overflow:auto: Again, this meets requirements
1, 2, and 5. Requirement 3 would also be achievable with a bit of
scripting.
C) Insane s + CSS + Scripting: This essentially meets all
requirements (maybe excluding 4, depending on what the actual
requirement is); although at a high development cost. (This would be
the "MSDN style" approach.)
D) HTML4 Frameset + HTML5 documents for frame contents: this meets
requirements 1, 2, 3, and 5 out of the box, it's an almost trivial
upgrade from any HTML4 web-app that takes a similar approach, and is
relatively easy to implement.

Finally, once it is shown that currently existing solutions can't
handle the use-case (which hasn't been shown: C and D both can, and A
and B can as well if a bit of scripting is added to handle the
resizing requirement), it would only be left to verify that your
proposal actually meets the requirements. There is a problem here,
however: What is your proposal? I'm not sure why you haven't described
your proposal. If you want the editor to change the spec, it's quite a
good idea to describe the changes you want to be made on the spec.

In summary, what you need to do is:
1) Correct me if I made any mistakes when trying to synthesize your use-case.
2) Clarify and justify Requirement 4.
3) Justify Requirement 5.
4) Describe your proposal.
5) Show how does your proposal meet all of the requirements for the use-case.

As far as this has gone, my impression is that you want a HTML5
Frameset document type that is exactly identical to the HTML 4
version. It is pointless to "update" a version of

Re: [whatwg] framesets

2009-10-10 Thread Markus Ernst


Peter Brawley schrieb:
 >So, if the people who discuss and define the HTML5 standard *do not 
like* framesets,

 >it is IMO reason enough for them to take them out of this standard.

Thwere we disagree. A main W3C responsibility is to facilitate the web. 
Removing a feature /which is used because use cases require it/ is 
destructive to the web by diminishing support for a required feature.


Frames are not part of HTML4 Strict. The existing HTML4 Frameset 
Standard will remain valid. AFAICS, unlike HTML4 Strict pages, you will 
be able to use valid HTML5 pages in HTML4 framesets, as the target 
attribute has been moved back into HTML5. So why do you insist in 
creating an HTML5 Frameset Standard?

Re: [whatwg] framesets

Edouard,

It seems you missed the start of this thread. One use case is
coordinated browsing of a large database-driven tree in one scrollable
subwindow and its nodes in another, under a header subwindow which
(usually) has a tree search control which can direct the tree wubwindow
to open & display down to the requested node. A frontend authentication
page determines access to the page and optionally CRUD access to any
combo of nodes. It must be possible to scroll either subwindow without
affecting the other in any way. Tree & node subwindows to be editable
and resizable. If a user does not have read access to a node, the node
(and anything downstream from that node) is not visible to her. As in
most standard database maintenance sites, data is not bookmarkable, so
no tree node is bookmarkable, ie once the user comes in to read and/or
manage the tree, the back button ignores all her tree moves & actions.
In sum, the look and feel should resemble
http://java.sun.com/javase/6/docs/api/?../technotes/guides/collections/index.html
or
http://publib.boulder.ibm.com/infocenter/wpdoc/v510/index.jsp?topic=/com.ibm.wp.zos.doc/wps/dgn_navtree.html,
plus (i) tree navigation should not add to the url stack and (ii) full
CRUD must be supported for selected users.

A second use case is a questionnaire with a set of 600+ numbered yes-no
answers in one xy-scrollable frame, an independently scrolling
summary/stat info on that answer sheet, with the same rules as above,
and optionally a third navigation/selection subwindow.

I searched the archives of this list for discussion of tree navigation &
frames. I found Andrew Fedoniouk
(http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html)
saying "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./" That was what I too concluded from searching books & the web on
the subject. Claims to the contrary made here are therefore surprising.
I asked for examples of those claims, that the above specs can be met
fully (i) with iframes (ii) without either frames or iframes. No-one
pointed at an example that meets the spec fully. Closest is the MSDN
site, which needs about ten times as much code as ours, and is tied to
an OS. No thanks.

What's the justification? The above, plus data trees are increasingly
important (eg see
http://www.artfulsoftware.com/mysqlbook/sampler/mysqled1ch20.html), the
interface needed to maintain them is as described, and such interfaces
can be developed more cheaply & quickly on a web page with PHP than with
desktop-oriented tools. The most straightforward way to implement that
interface on a web page is the frameset (which might have a little
something to do with why IBM and Sun use framesets to meet similar specs).

Framesets are commonly used to present trees and some other
master-detail data structures. Removing the frameset from HTML5 is a
mistake.

Eduard Pascual wrote:

I have been following this discussion for many hours and it's getting
tiring. In addition, it doesn't seem to be leading anywhere; so please
let me suggest some ideas that may, at least, help it advance:

First: you have been asking for "counter-examples" (and you have been
given the MSDN one), but you haven't provided any specific example to
begin with. That would make a better starting point.

Second: you reject sound arguments claiming that "the use case
requires otherwise", but what's your use-case? Without clearly
specifying the use case, your arguments based on it aren't going to be
taken too seriously: they are basically based on nothing, until you
properly define the case they are supposedly based on. To specify a
use-case in a way that will be taken seriously by the editor and other
contributors:
- Clearly define the problem you are trying to solve. When doing so,
describe the problem in a way that is independent to the solution you
are proposing. For example, if you look on the archives, you'll see
that the use case for RDFa was often defined as "including RDF triples
on webpages": this didn't work because that's not the problem, RDF is
the solution. The same way, if you describe the need as "allowing
on HTML5" you won't get anywhere: that's your own
suggestion to address the need, but which is the need?
Make sure that your use-case addresses real-world problems.
- Clearly specify and justify the requirements. Keep in mind that
"because the client wants it" is not enough justification; you'd need
to get an answer to "why does the client want it?". For example, if
someone hired me to build a web app that takes control of the users'
computer, I might come to the lists and ask for a feature to implement
that, based on the point that "the client wants it": that'd be
pointless and would go nowhere.

Third: once you have a well-defined use-case (or ideall

Re: [whatwg] framesets

2009-10-09 Thread Eduard Pascual

I have been following this discussion for many hours and it's getting
tiring. In addition, it doesn't seem to be leading anywhere; so please
let me suggest some ideas that may, at least, help it advance:

First: you have been asking for "counter-examples" (and you have been
given the MSDN one), but you haven't provided any specific example to
begin with. That would make a better starting point.

Second: you reject sound arguments claiming that "the use case
requires otherwise", but what's your use-case? Without clearly
specifying the use case, your arguments based on it aren't going to be
taken too seriously: they are basically based on nothing, until you
properly define the case they are supposedly based on. To specify a
use-case in a way that will be taken seriously by the editor and other
contributors:
- Clearly define the problem you are trying to solve. When doing so,
describe the problem in a way that is independent to the solution you
are proposing. For example, if you look on the archives, you'll see
that the use case for RDFa was often defined as "including RDF triples
on webpages": this didn't work because that's not the problem, RDF is
the solution. The same way, if you describe the need as "allowing
 on HTML5" you won't get anywhere: that's your own
suggestion to address the need, but which is the need?
Make sure that your use-case addresses real-world problems.
- Clearly specify and justify the requirements. Keep in mind that
"because the client wants it" is not enough justification; you'd need
to get an answer to "why does the client want it?". For example, if
someone hired me to build a web app that takes control of the users'
computer, I might come to the lists and ask for a feature to implement
that, based on the point that "the client wants it": that'd be
pointless and would go nowhere.

Third: once you have a well-defined use-case (or ideally, several
use-cases), you have a chance to get your proposal being taken
seriously. To do so, specify what you are proposing:
- State why currently existing solutions don't meet the requirements.
As far as this has gone, the only requirements that apparently aren't
met by  and other alternatives are the "break deep-linking"
and "break navigation" ones. Besides of the fact that you still need
to justify such requirements, that's actually easy to achieve with a
bit of ugly scripting.
- Describe your solution. State clearly how/why it meets each of the
requirements. Also, try to describe the specific changes required on
the spec.

If you manage to do that, your proposal will be definitely be taken
much more seriously.

Regards,
Eduard Pascual

Re: [whatwg] framesets

Thomas,

>For example, compare:
>http://msdn.microsoft.com/en-us/library/system.collections.generic.aspx
>with
http://java.sun.com/javase/6/docs/api/?../technotes/guides/collections/index.html
>(and note that this URL cannot be find in *any* link anywhere in the
>JavaDoc, and requires JavaScript to display the "The Collections
>Framework" page; while the MSDN page, even without JavaScript,
>correctly displays the "main content" and can still be navigated,
>though with highly degraded usability).
>See also 
>http://help.adobe.com/en_US/AS3LCR/Flash_10.0/?flash/accessibility/AccessibilityProperties.html&flash/accessibility/class-list.html

>(frames, same issue as JavaDoc, with the added possibility to control
>the "classList" frame's content; only discoverable if you read the
>JavaScript code in the frameset source)

Indeed. I prefer the Java & Sun framesets to the MSDN page, even if they 
pile up tree items in the url stack, but that's not the point. Nor is 
the point that a Microsoft maven might prefer the MSDN solution.

Quite apart from OS dependence issues, the points are (i) there are use 
cases for which the Java & Sun framesets are simple, correct solutions, 
and the MSDN solution is not, and (ii) revisions in standards ought not 
to render existing use-case-correct solutions unusable with other new 
features of the new standard.

PB

-

Thomas Broyer wrote:

On Fri, Oct 9, 2009 at 10:33 PM, Peter Brawley  wrote:

Boris,

use cases that the W3C wants to discourage ...

That W3C mindset promotes no greater good; it just imposes an idea of what
use cases should and shouldn't specify. Might as wellwrite popuo removal
into HTML5.

The use cases can still be addressed with  and a bit of pain if
resizing is desired, as far as I can tell.

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."

Usability of *HyperText* Markup Language involves being able to *link
to* the frameset as it is presented (which also means bookmarking).
Most users don't understand the concept of frames and don't understand
that when they bookmark a frameset (after having navigated within the
frames), what is bookmarked is not the "page" they were looking at
when they clicked the "bookmark this page" button.
While this can be made to work with JavaScript and (ab)using the #hash
part of the URL (à la AJAX applications' browser history
handling/management), it however is a usability issue with frames to
begin with.

I've not seen a counterexample. Have you?

I find MSDN as it is now much more usable than when it used frames,
even if that means that the treeview state (which subtree is
opened/closed) isn't preserves when navigating (but trees are not
"first class citizen" of web pages, they always involve JavaScript,
and in this case, localStorage or sessionStorage (or cookies, etc.)
could preserve the treeview state between pages; for the record,
 was an attempt to make data grids, and trees, become
first-class citizens, but it wasn't "stable" enough and has been
removed for Last Call).
For example, compare:
http://msdn.microsoft.com/en-us/library/system.collections.generic.aspx
with
http://java.sun.com/javase/6/docs/api/?../technotes/guides/collections/index.html
(and note that this URL cannot be find in *any* link anywhere in the
JavaDoc, and requires JavaScript to display the "The Collections
Framework" page; while the MSDN page, even without JavaScript,
correctly displays the "main content" and can still be navigated,
though with highly degraded usability).

See also 
http://help.adobe.com/en_US/AS3LCR/Flash_10.0/?flash/accessibility/AccessibilityProperties.html&flash/accessibility/class-list.html
(frames, same issue as JavaDoc, with the added possibility to control
the "classList" frame's content; only discoverable if you read the
JavaScript code in the frameset source)

So this is all about assuming that the bit of pain will be enough of an
inconvenience
for authors that they will either address the use case in some way not
involving iframes
at all (and which presumably has a lower pain threshild; what is this way?)

As above, no-one seems able to point to a non-frameset solution.

It depends if you consider the MSDN a non-frameset solution to your
"problem"; but I guess you're very attached to the "doesn't affect
treeview state and scroll position" thing (which isn't impossible to
solve; see above)

IMO, your mysqlquerytree example would be better solved using AJAX
(and innerHTML to inject the retrieved "web parts"): no need for
sessions on the server-side –at least for the treeview state storage–,
which means a more "RESTful" approach, with caching made possible
(even if it is only Vary:Cookie/Cache-Con

Re: [whatwg] framesets

Markus,

> I think that the discussion if or not there may be a use case where 
framesets are "good" is not the point.

We agree there, and I'd go further: declaring a mechanism for hiding 
intrapage links "bad" is an overreach, to put it mildly.

>So, if the people who discuss and define the HTML5 standard *do not 
like* framesets,

>it is IMO reason enough for them to take them out of this standard.

There we disagree. A main W3C responsibility is to facilitate the web. 
Removing a feature /which is used because use cases require it/ is 
destructive to the web by diminishing support for a required feature.

PB

-

Markus Ernst wrote:

Peter Brawley schrieb:

Eduard,

 >Everything that can be achieved with  can be done through
 >+.

If that's so, someone ought to be able to point at some examples.

I think that the discussion if or not there may be a use case where 
framesets are "good" is not the point.

Supposing that someone can produce examples, the argument for 
removing frames from HTML5 becomes: "frameset has been in HTML till 
now, /but is being removed because we do not like it/. If you insist 
on such use cases, re-architect them." That's a misuse of standards.

This is rather the point. There might be a use case where dictatorship 
is good - only a dictator might i.e. make laws to really protect the 
environment, which would not be possible in a democracy. There might 
even be a use case where chemical weapons are good - they might i.e. 
serve to fight a rat plague somewhere in a third-world country. Still 
we (well, I hope most of us) *do not like* dictatorship and chemical 
weapons. This is reason enough to try to contribute to a world where 
they are not wide-spread.

So, if the people who discuss and define the HTML5 standard *do not 
like* framesets, it is IMO reason enough for them to take them out of 
this standard. This will, as stated already by several posters, not 
prevent you from using a frameset to do something "good" with it, and 
you will be as safe as you are now, as UAs will support legacy content 
for the years to come.

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

Re: [whatwg] framesets

2009-10-09 Thread Thomas Broyer

On Fri, Oct 9, 2009 at 10:33 PM, Peter Brawley  wrote:
> Boris,
>
>> use cases that the W3C wants to discourage ...
>
> That W3C mindset promotes no greater good; it just imposes an idea of what
> use cases should and shouldn't specify. Might as wellwrite popuo removal
> into HTML5.
>
>> The use cases can still be addressed with  and a bit of pain if
>> resizing is desired, as far as I can tell.
>
> 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."

Usability of *HyperText* Markup Language involves being able to *link
to* the frameset as it is presented (which also means bookmarking).
Most users don't understand the concept of frames and don't understand
that when they bookmark a frameset (after having navigated within the
frames), what is bookmarked is not the "page" they were looking at
when they clicked the "bookmark this page" button.
While this can be made to work with JavaScript and (ab)using the #hash
part of the URL (à la AJAX applications' browser history
handling/management), it however is a usability issue with frames to
begin with.

> I've not seen a counterexample. Have you?

I find MSDN as it is now much more usable than when it used frames,
even if that means that the treeview state (which subtree is
opened/closed) isn't preserves when navigating (but trees are not
"first class citizen" of web pages, they always involve JavaScript,
and in this case, localStorage or sessionStorage (or cookies, etc.)
could preserve the treeview state between pages; for the record,
 was an attempt to make data grids, and trees, become
first-class citizens, but it wasn't "stable" enough and has been
removed for Last Call).
For example, compare:
http://msdn.microsoft.com/en-us/library/system.collections.generic.aspx
with
http://java.sun.com/javase/6/docs/api/?../technotes/guides/collections/index.html
(and note that this URL cannot be find in *any* link anywhere in the
JavaDoc, and requires JavaScript to display the "The Collections
Framework" page; while the MSDN page, even without JavaScript,
correctly displays the "main content" and can still be navigated,
though with highly degraded usability).

See also 
http://help.adobe.com/en_US/AS3LCR/Flash_10.0/?flash/accessibility/AccessibilityProperties.html&flash/accessibility/class-list.html
(frames, same issue as JavaDoc, with the added possibility to control
the "classList" frame's content; only discoverable if you read the
JavaScript code in the frameset source)

>>So this is all about assuming that the bit of pain will be enough of an
>> inconvenience
>>for authors that they will either address the use case in some way not
>> involving iframes
>>at all (and which presumably has a lower pain threshild; what is this way?)
>
> As above, no-one seems able to point to a non-frameset solution.

It depends if you consider the MSDN a non-frameset solution to your
"problem"; but I guess you're very attached to the "doesn't affect
treeview state and scroll position" thing (which isn't impossible to
solve; see above)

IMO, your mysqlquerytree example would be better solved using AJAX
(and innerHTML to inject the retrieved "web parts"): no need for
sessions on the server-side –at least for the treeview state storage–,
which means a more "RESTful" approach, with caching made possible
(even if it is only Vary:Cookie/Cache-Control:private, it's still
better than server state), scalability improvements (less data –state–
kept on the server, less requests to the server –caching *and* the
fact that it's a one-page thing: once you've loaded a subtree, even if
you collapse and re-open it, you don't have to reload it–)
... just like the Google Document Reader (here showing the GWT 1.5 doc):
http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

Re: [whatwg] framesets

2009-10-09 Thread Markus Ernst


Peter Brawley schrieb:

Eduard,

 >Everything that can be achieved with  can be done through
 >+.

If that's so, someone ought to be able to point at some examples.

I think that the discussion if or not there may be a use case where 
framesets are "good" is not the point.


Supposing that someone can produce examples, the argument for removing 
frames from HTML5 becomes: "frameset has been in HTML till now, /but is 
being removed because we do not like it/. If you insist on such use 
cases, re-architect them." That's a misuse of standards.


This is rather the point. There might be a use case where dictatorship 
is good - only a dictator might i.e. make laws to really protect the 
environment, which would not be possible in a democracy. There might 
even be a use case where chemical weapons are good - they might i.e. 
serve to fight a rat plague somewhere in a third-world country. Still we 
(well, I hope most of us) *do not like* dictatorship and chemical 
weapons. This is reason enough to try to contribute to a world where 
they are not wide-spread.


So, if the people who discuss and define the HTML5 standard *do not 
like* framesets, it is IMO reason enough for them to take them out of 
this standard. This will, as stated already by several posters, not 
prevent you from using a frameset to do something "good" with it, and 
you will be as safe as you are now, as UAs will support legacy content 
for the years to come.

Re: [whatwg] framesets

2009-10-09 Thread Eduard Pascual

On Fri, Oct 9, 2009 at 10:39 PM, Peter Brawley  wrote:
> Eduard,
>
>>Everything that can be achieved with  can be done through
>>+.
>
> If that's so, someone ought to be able to point at some examples.
I just got something even better [1]: it doesn't even use : it
goes away with s, CSS, and scripting.
+ would make things simpler, since the page would only
need to add a bit of script to handle the resizing.

> Supposing that someone can produce examples, the argument for removing
> frames from HTML5 becomes: "frameset has been in HTML till now, but is being
> removed because we do not like it. If you insist on such use cases,
> re-architect them." That's a misuse of standards.
That's not the argument. It would be something more like "frameset has
arisen several issues and doesn't solve anything that can't be solved
in a different way. If you insist on using frameset, just forget about
HTML5 validation."
After all, the only purpose of validation is to have a hint of
potential interoperability and accessibility issues. If you are using
, you should already be aware of the issues you might face,
so you don't need a validator to hint them to you.

>>What'd be the point of keeping two sources of issues when one can be
>>enough to cover all use-cases?
>
> If your premiss is correct, backward compatibility.
Backward compatibility is not handled at the language level, but at
the application level.  will not stop working: browsers will
keep handling it as they have until now. Leaving  out of the
spec only affects validation.
Furthermore, AFAIK it's entirely valid to have an HTML4 Frameset
doctype for a .html file, and refer from the  to files that
use the HTML5 doctype and new features. Since  has always
been intended to be used only from a "frameset page" or "master page",
what purpose would serve allowing them on a non-frameset doctype?
Furthermore, since HTML5 adds no features at all to , would
it make any sense to define a "HTML5 Frameset doctype"?

In summary: you can still use  as much as you want; and
trigger either "quirks" or "standard" mode on the client side. In
addition, if you manage properly your files and doctypes, you can even
have everything validating. What are you exactly asking for?

Regards,
Eduard Pascual

[1]: 
http://msdn.microsoft.com/en-us/library/system.windows.forms.htmldocument.aspx

Re: [whatwg] framesets

Brian,

>There are no switches that put the browser in HTML5 mode or anything 
like that;
>the only switch is based on whether you have one of a few given 
doctypes, which

>only affects whether you're put in quirks mode or in standards mode.

Why relegate a perfectly sound use case to a cul-de-sac? It would be 
better to add to frames standards such that they're simpler to use.

PB

-

Brian Campbell wrote:

On Oct 9, 2009, at 2:47 PM, Peter Brawley wrote:

I'm arguing that framesets have been part of HTML4, developers used 
them in good faith, and removing them from HTML5 unfairly & 
arbitrarily imposes a Hobson's choice of keeping existing 
functionality while foregoing new HTML5 functionality, or 
re-architecting existing functionality in order to use new HTML5 
functionality.

No, there is not choice you have to make. Framesets will still work in 
HTML5, they just won't allow you to validate. The page you cited, 
 already 
doesn't validate against HTML 4.01 (you are missing a doctype, and 
missing a title element), so I'm not sure why validation should 
suddenly matter. There are no features in HTML5 that are being 
withheld from pages which don't conform to the spec. There are no 
switches that put the browser in HTML5 mode or anything like that; the 
only switch is based on whether you have one of a few given doctypes, 
which only affects whether you're put in quirks mode or in standards 
mode.

-- Brian

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

Re: [whatwg] framesets

Eduard,

>Everything that can be achieved with  can be done through
>+.

If that's so, someone ought to be able to point at some examples.

Supposing that someone can produce examples, the argument for removing 
frames from HTML5 becomes: "frameset has been in HTML till now, /but is 
being removed because we do not like it/. If you insist on such use 
cases, re-architect them." That's a misuse of standards.

>What'd be the point of keeping two sources of issues when one can be
>enough to cover all use-cases?

If your premiss is correct, backward compatibility.

PB

--

Eduard Pascual wrote:

On Fri, Oct 9, 2009 at 10:17 PM, Peter Brawley  wrote:

So why *are*
frames banned, if you can easily replace them with iframes and get the
exact same lousy behavior?  Because iframes also have less evil uses,
and frames don't, I guess?

Designation of reasonable uses as "evil" is authoritarian nonsense.

PB

Both  and  are a source of several issues.
Everything that can be achieved with  can be done through
+.
What'd be the point of keeping two sources of issues when one can be
enough to cover all use-cases?
Since  can handle all the use-cases for , and some
that  just can't, it's obvious which one to drop.

Regards,
Eduard Pascual

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

Re: [whatwg] framesets

Boris,

> use cases that the W3C wants to discourage ...

That W3C mindset promotes no greater good; it just imposes an idea of 
what use cases should and shouldn't specify. Might as wellwrite popuo 
removal into HTML5.

> The use cases can still be addressed with  and a bit of pain 
if resizing is desired, as far as I can tell. 

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?

>So this is all about assuming that the bit of pain will be enough of 
an inconvenience
>for authors that they will either address the use case in some way not 
involving iframes
>at all (and which presumably has a lower pain threshild; what is this 
way?)

As above, no-one seems able to point to a non-frameset solution.

>or not address
>the use case at all (unlikely, since they're being paid to address it). 

IMO money has no place in this discussion.

> Since UAs must continue supporting framesets anyway, the reasoning 
behind removing them seems somewhat weak to me.

Yes.

PB

-

Boris Zbarsky wrote:

On 10/9/09 2:55 PM, Peter Brawley wrote:

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

This isn't really a convincing argument.  There are various other 
things that are part of HTML 4.01 that are worth removing and have 
been removed.

That said, I'm not sure why there's a worry about what's in the 
standard given the 
http://www.artfulsoftware.com/infotree/mysqlquerytree.php example 
(which doesn't actually validate per the HTML 4.01 standard, since 
it's missing a doctype).

On a general note, though, the reasoning behind removing framesets 
seems to be that they make it very easy to address specific authoring 
use cases that the W3C wants to discourage, right?  The use cases can 
still be addressed with  and a bit of pain if resizing is 
desired, as far as I can tell.  So this is all about assuming that the 
bit of pain will be enough of an inconvenience for authors that they 
will either address the use case in some way not involving iframes at 
all (and which presumably has a lower pain threshild; what is this 
way?) or not address the use case at all (unlikely, since they're 
being paid to address it).  Since UAs must continue supporting 
framesets anyway, the reasoning behind removing them seems somewhat 
weak to me.

-Boris

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

Re: [whatwg] framesets

2009-10-09 Thread Eduard Pascual

On Fri, Oct 9, 2009 at 10:17 PM, Peter Brawley  wrote:
>>So why *are*
>>frames banned, if you can easily replace them with iframes and get the
>>exact same lousy behavior?  Because iframes also have less evil uses,
>>and frames don't, I guess?
>
> Designation of reasonable uses as "evil" is authoritarian nonsense.
>
> PB

Both  and  are a source of several issues.
Everything that can be achieved with  can be done through
+.
What'd be the point of keeping two sources of issues when one can be
enough to cover all use-cases?
Since  can handle all the use-cases for , and some
that  just can't, it's obvious which one to drop.

Regards,
Eduard Pascual

Re: [whatwg] framesets

2009-10-09 Thread Yuvalik Webdesign

> From: Peter Brawley
> Designation of reasonable uses as "evil" is authoritarian nonsense.

Sorry to break into the discussion, but as pointed out, you can still use 
frames if you want to. The way I see it you have three choices:

1) Keep using HTML4
2) Loose the frames and use HTML5
3) Use HTML5 but also keep using the HTML4 frames

Now, option 3 might sound silly, but you could always say that part of your 
pages validate in HTML4 and the other part in HTML5. In essence, the validators 
tell you nothing about how your pages behave in browsers, and as long as your 
code is sound (which doesn't have to be valid mind you) it will render 
perfectly, and will continue to do so for a very long time I suspect.

Now I am not advocating such a course of action, but I could see how it would 
benefit in certain situations. Keep in mind that the only authority the 
spec-writers have is over the spec itself, not over your use of it.

Evert

Re: [whatwg] framesets


So why *are*
frames banned, if you can easily replace them with iframes and get the
exact same lousy behavior?  Because iframes also have less evil uses,
and frames don't, I guess?


Designation of reasonable uses as "evil" is authoritarian nonsense.

PB

-



Aryeh Gregor wrote:

On Fri, Oct 9, 2009 at 2:47 PM, Peter Brawley  wrote:
  

Right, the point is that the use case specifies tree navigation to be
entirely independent of navigation to and from the page, that tree and
detail subwindows be independently scrollable & resizable, and that tree
nodes not be externally linkable. The response that the client ought not to
want this is, well, beyond W3C's brief.



This is actually the WHATWG list, not the W3C.  But in any case, both
organizations think it's completely appropriate for them to pressure
authors to avoid bad features.  I guess you can feel free to argue
that they shouldn't, but I don't think you'll convince them.

  

I'm arguing that framesets have been part of HTML4, developers used them in
good faith, and removing them from HTML5 unfairly & arbitrarily imposes a
Hobson's choice of keeping existing functionality while foregoing new HTML5
functionality, or re-architecting existing functionality in order to use new
HTML5 functionality.



You aren't *forced*.  You can make a document that uses both frames
and HTML5 features.  It will work, it's just not valid HTML5.

On Fri, Oct 9, 2009 at 2:55 PM, Peter Brawley  wrote:
  

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



As defined by who?  For instance, the W3C's mission is "To lead the
World Wide Web to its full potential by developing protocols and
guidelines that ensure long-term growth for the Web."
  That includes prohibiting things it
considers harmful.

  

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



Well, yes.  The WHATWG and W3C are standards bodies.  Standards are,
by definition, things that impose one way of doing things.

On Fri, Oct 9, 2009 at 2:57 PM, Boris Zbarsky  wrote:
  

I don't see how they wouldn't.  Everything you can accomplish with
 and  you can do with  plus gobs of javascript to
make the drag-resizing work (probably badly, unlike the UA-provided resizing
for ), no?  Oh, and more hacks to get the initial sizing right and
such, of course...



Ah, I didn't understand how navigation in iframes works.  So why *are*
frames banned, if you can easily replace them with iframes and get the
exact same lousy behavior?  Because iframes also have less evil uses,
and frames don't, I guess?



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

Re: [whatwg] framesets

2009-10-09 Thread Jonas Sicking

On Fri, Oct 9, 2009 at 12:13 PM, Aryeh Gregor  wrote:
> On Fri, Oct 9, 2009 at 2:57 PM, Boris Zbarsky  wrote:
>> I don't see how they wouldn't.  Everything you can accomplish with
>>  and  you can do with  plus gobs of javascript to
>> make the drag-resizing work (probably badly, unlike the UA-provided resizing
>> for ), no?  Oh, and more hacks to get the initial sizing right and
>> such, of course...
>
> Ah, I didn't understand how navigation in iframes works.  So why *are*
> frames banned, if you can easily replace them with iframes and get the
> exact same lousy behavior?  Because iframes also have less evil uses,
> and frames don't, I guess?

The big difference is that s can be used in good ways,
framesets essentially can't.

Another reason do deprecate  but not  is that we
don't need *two* ways to make poorly behaving pages.

/ Jonas

Re: [whatwg] framesets

2009-10-09 Thread Brian Campbell


On Oct 9, 2009, at 2:47 PM, Peter Brawley wrote:

I'm arguing that framesets have been part of HTML4, developers used  
them in good faith, and removing them from HTML5 unfairly &  
arbitrarily imposes a Hobson's choice of keeping existing  
functionality while foregoing new HTML5 functionality, or re- 
architecting existing functionality in order to use new HTML5  
functionality.


No, there is not choice you have to make. Framesets will still work in  
HTML5, they just won't allow you to validate. The page you cited,  already doesn't validate against HTML 4.01 (you are missing a  
doctype, and missing a title element), so I'm not sure why validation  
should suddenly matter. There are no features in HTML5 that are being  
withheld from pages which don't conform to the spec. There are no  
switches that put the browser in HTML5 mode or anything like that; the  
only switch is based on whether you have one of a few given doctypes,  
which only affects whether you're put in quirks mode or in standards  
mode.


-- Brian

Re: [whatwg] framesets

2009-10-09 Thread Boris Zbarsky


On 10/9/09 2:55 PM, Peter Brawley wrote:

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


This isn't really a convincing argument.  There are various other things 
that are part of HTML 4.01 that are worth removing and have been removed.


That said, I'm not sure why there's a worry about what's in the standard 
given the http://www.artfulsoftware.com/infotree/mysqlquerytree.php 
example (which doesn't actually validate per the HTML 4.01 standard, 
since it's missing a doctype).


On a general note, though, the reasoning behind removing framesets seems 
to be that they make it very easy to address specific authoring use 
cases that the W3C wants to discourage, right?  The use cases can still 
be addressed with  and a bit of pain if resizing is desired, as 
far as I can tell.  So this is all about assuming that the bit of pain 
will be enough of an inconvenience for authors that they will either 
address the use case in some way not involving iframes at all (and which 
presumably has a lower pain threshild; what is this way?) or not address 
the use case at all (unlikely, since they're being paid to address it). 
 Since UAs must continue supporting framesets anyway, the reasoning 
behind removing them seems somewhat weak to me.


-Boris

Re: [whatwg] framesets

On Fri, Oct 9, 2009 at 2:47 PM, Peter Brawley  wrote:
> Right, the point is that the use case specifies tree navigation to be
> entirely independent of navigation to and from the page, that tree and
> detail subwindows be independently scrollable & resizable, and that tree
> nodes not be externally linkable. The response that the client ought not to
> want this is, well, beyond W3C's brief.

This is actually the WHATWG list, not the W3C.  But in any case, both
organizations think it's completely appropriate for them to pressure
authors to avoid bad features.  I guess you can feel free to argue
that they shouldn't, but I don't think you'll convince them.

> I'm arguing that framesets have been part of HTML4, developers used them in
> good faith, and removing them from HTML5 unfairly & arbitrarily imposes a
> Hobson's choice of keeping existing functionality while foregoing new HTML5
> functionality, or re-architecting existing functionality in order to use new
> HTML5 functionality.

You aren't *forced*.  You can make a document that uses both frames
and HTML5 features.  It will work, it's just not valid HTML5.

On Fri, Oct 9, 2009 at 2:55 PM, Peter Brawley  wrote:
> It's not your brief to decide what's beneficial for a client.

As defined by who?  For instance, the W3C's mission is "To lead the
World Wide Web to its full potential by developing protocols and
guidelines that ensure long-term growth for the Web."
  That includes prohibiting things it
considers harmful.

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

Well, yes.  The WHATWG and W3C are standards bodies.  Standards are,
by definition, things that impose one way of doing things.

On Fri, Oct 9, 2009 at 2:57 PM, Boris Zbarsky  wrote:
> I don't see how they wouldn't.  Everything you can accomplish with
>  and  you can do with  plus gobs of javascript to
> make the drag-resizing work (probably badly, unlike the UA-provided resizing
> for ), no?  Oh, and more hacks to get the initial sizing right and
> such, of course...

Ah, I didn't understand how navigation in iframes works.  So why *are*
frames banned, if you can easily replace them with iframes and get the
exact same lousy behavior?  Because iframes also have less evil uses,
and frames don't, I guess?

Re: [whatwg] framesets

2009-10-09 Thread Boris Zbarsky


On 10/9/09 2:19 PM, Aryeh Gregor wrote:

I don't see how iframes would allow you to deliberately mess up
navigation in the same way as frames do.


I don't see how they wouldn't.  Everything you can accomplish with 
 and  you can do with  plus gobs of javascript 
to make the drag-resizing work (probably badly, unlike the UA-provided 
resizing for ), no?  Oh, and more hacks to get the initial 
sizing right and such, of course...


-Boris

Re: [whatwg] framesets

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  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.   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  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

Re: [whatwg] framesets

Thomas,

>Framesets, iframes, AJAX+innerHTML all allow this; you can't present
>this as an argument for frameset or against their removal (though,
>actually, I think you didn't, and the discussion just wen this road

Right, the point is that the use case specifies tree navigation to be 
entirely independent of navigation to and from the page, that tree and 
detail subwindows be independently scrollable & resizable, and that tree 
nodes /not/ be externally linkable. The response that the client ought 
not to want this is, well, beyond W3C's brief.

>you could just use iframes too to the same effect,
>except frame resizing, that would need some additional scripting; did
>I adequately describe your argument here?)

I've been looking, but I've not seen an adequate iframe implementation 
of this spec.

I'm arguing that framesets have been part of HTML4, developers used them 
in good faith, and removing them from HTML5 unfairly & arbitrarily 
imposes a Hobson's choice of keeping existing functionality while 
foregoing new HTML5 functionality, or re-architecting existing 
functionality in order to use new HTML5 functionality.

PB

-

Thomas Broyer wrote:

On Fri, Oct 9, 2009 at 7:47 PM, Peter Brawley  wrote:

A design goal of this use case is to isolate individual framed items from
URL back/forward/history.external linking. Analagous to watching a picture
show where selecting N pictures does not commit you to hitting the Back
button N times to get back out.

Why shouldn't it?

Because the use case demands otherwise.

It's how all other links work. Behavior should be consistent.

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.

Framesets, iframes, AJAX+innerHTML all allow this; you can't present
this as an argument for frameset or against their removal (though,
actually, I think you didn't, and the discussion just wen this road
while the use case you were showing is that clicking on a link in any
frame, that loads a new doc within this same frame doesn't have any
side effect on the other frames; for instance, you do not "lose" your
scroll position in the other frames, MSDN doesn't behave exactly the
same here; though you could just use iframes too to the same effect,
except frame resizing, that would need some additional scripting; did
I adequately describe your argument here?)

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

Re: [whatwg] framesets

On Fri, Oct 9, 2009 at 1:47 PM, Peter Brawley  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.   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  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.

Re: [whatwg] framesets

2009-10-09 Thread Thomas Broyer

On Fri, Oct 9, 2009 at 7:47 PM, Peter Brawley  wrote:
>>> A design goal of this use case is to isolate individual framed items from
>>> URL back/forward/history.external linking. Analagous to watching a picture
>>> show where selecting N pictures does not commit you to hitting the Back
>>> button N times to get back out.
>>
>>Why shouldn't it?
>
> Because the use case demands otherwise.
>
>> It's how all other links work. Behavior should be consistent.
>
> 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.

Framesets, iframes, AJAX+innerHTML all allow this; you can't present
this as an argument for frameset or against their removal (though,
actually, I think you didn't, and the discussion just wen this road
while the use case you were showing is that clicking on a link in any
frame, that loads a new doc within this same frame doesn't have any
side effect on the other frames; for instance, you do not "lose" your
scroll position in the other frames, MSDN doesn't behave exactly the
same here; though you could just use iframes too to the same effect,
except frame resizing, that would need some additional scripting; did
I adequately describe your argument here?)


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

Re: [whatwg] framesets

> Oy, from the fact that users find web page links useful, it does not 
follow

> that all identified content ought to be so linked.

>It suggests that not linking is a serious drawback.

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.

> A design goal of this use case is to isolate individual framed items from
> URL back/forward/history.external linking. Analagous to watching a 
picture

> show where selecting N pictures does not commit you to hitting the Back
> button N times to get back out.

>Why shouldn't it?

Because the use case demands otherwise.

> It's how all other links work. Behavior should be consistent.

/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.

> More significantly, each item may have its own permission setting.

>Why are frames useful for that? You can just display a permissions
>error if the user is unauthorized.

The use case specifies otherwise.

> This use case needs to isolate items within the page from
> back/forward/history and external links.

>Why? That seems to detract from the utility here, not add to it.

Already explained. So that a user may enter and exit the frameset as one 
page

PB

-

Aryeh Gregor wrote:
On Fri, Oct 9, 2009 at 12:55 PM, Peter Brawley  
wrote:
Oy, from the fact that users find web page links useful, it does not 
follow

that all identified content ought to be so linked.

It suggests that not linking is a serious drawback.

A design goal of this use case is to isolate individual framed items from
URL back/forward/history.external linking. Analagous to watching a 
picture

show where selecting N pictures does not commit you to hitting the Back
button N times to get back out.

Why shouldn't it? It's how all other links work. Behavior should be
consistent.

More significantly, each item may have its
own permission setting.

Why are frames useful for that? You can just display a permissions
error if the user is unauthorized.

This use case needs to isolate items within the page from
back/forward/history and external links.

Why? That seems to detract from the utility here, not add to it.

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

Re: [whatwg] framesets

On Fri, Oct 9, 2009 at 12:55 PM, Peter Brawley  wrote:
> Oy, from the fact that users find web page links useful, it does not follow
> that all identified content ought to be so linked.

It suggests that not linking is a serious drawback.

> A design goal of this use case is to isolate individual framed items from
> URL back/forward/history.external linking. Analagous to watching a picture
> show where selecting N pictures does not commit you to hitting the Back
> button N times to get back out.

Why shouldn't it?  It's how all other links work.  Behavior should be
consistent.

> More significantly, each item may have its
> own permission setting.

Why are frames useful for that?  You can just display a permissions
error if the user is unauthorized.

> This use case needs to isolate items within the page from
> back/forward/history and external links.

Why?  That seems to detract from the utility here, not add to it.

Re: [whatwg] framesets


Try bookmarking a specific page, giving someone a link to a specific
page . . . you can't.  There's one URL for the whole thing, no matter
what page you have open.  It seems you can't even use the back and
forward buttons -- navigating doesn't create a new history entry.
(This appears to be true at least in Firefox and Chrome.)  Linking is
what makes the World Wide Web work, and frames completely break it.


Oy, from the fact that users find web page links useful, it does not 
follow that all identified content ought to be so linked.


A /design goal/ of this use case is to isolate individual framed items 
from URL back/forward/history.external linking. Analagous to watching a 
picture show where selecting N pictures does not commit you to hitting 
the Back button N times to get back out. More significantly, each item 
may have its own permission setting.


Linking is /one functionality/ that makes the web work. /It's not the 
only one/. This use case /needs to isolate/ items within the page from 
back/forward/history and external links.


PB



Thomas Broyer wrote:

On Fri, Oct 9, 2009 at 6:04 PM, Aryeh Gregor  wrote:
  

On Thu, Oct 8, 2009 at 10:41 PM, Peter Brawley  wrote:



A small example is at
http://www.artfulsoftware.com/infotree/mysqlquerytree.php. All the content
is from a MySQL db. It's a small part of the tree & read-only. Our networks
(and some clients) run edit-enabled versions of that frameset. The tree can
be any size. Some client implementations have an extra frame on the right.
  

Try bookmarking a specific page, giving someone a link to a specific
page . . . you can't.  There's one URL for the whole thing, no matter
what page you have open.  It seems you can't even use the back and
forward buttons -- navigating doesn't create a new history entry.
(This appears to be true at least in Firefox and Chrome.)  Linking is
what makes the World Wide Web work, and frames completely break it.


[...]
  

 I don't know why back and forward don't work in the browsers I tried
it in, but they don't do that either.



That's because it uses parent.frames["details"].location.replace(...)
and parent.frames["tree"].location.replace(...)

(in this case, I'd talk about a "developer [who has] mismanaged the
Back button")

  

 Removing a feature that's
intrinsically broken is absolutely the correct use of the standards
process.



I'd add however that replacing a frameset with iframes doesn't solve
the problem. MSDN (online) correctly (IMO) does *not* use either
frames or iframes, and still works great (using JavaScript, but
Peter's example requires JavaScript too). i'd even say it works better
than Peter's example because the tree state is maintained on the
client-side, which means requests to the server can be cached
efficiently (and additionally are lighter-weight and don't even
require server-side processing)

  




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

Re: [whatwg] framesets

2009-10-09 Thread Thomas Broyer

On Fri, Oct 9, 2009 at 6:04 PM, Aryeh Gregor  wrote:
> On Thu, Oct 8, 2009 at 10:41 PM, Peter Brawley  
> wrote:
>
>> A small example is at
>> http://www.artfulsoftware.com/infotree/mysqlquerytree.php. All the content
>> is from a MySQL db. It's a small part of the tree & read-only. Our networks
>> (and some clients) run edit-enabled versions of that frameset. The tree can
>> be any size. Some client implementations have an extra frame on the right.
>
> Try bookmarking a specific page, giving someone a link to a specific
> page . . . you can't.  There's one URL for the whole thing, no matter
> what page you have open.  It seems you can't even use the back and
> forward buttons -- navigating doesn't create a new history entry.
> (This appears to be true at least in Firefox and Chrome.)  Linking is
> what makes the World Wide Web work, and frames completely break it.
[...]
>  I don't know why back and forward don't work in the browsers I tried
> it in, but they don't do that either.

That's because it uses parent.frames["details"].location.replace(...)
and parent.frames["tree"].location.replace(...)

(in this case, I'd talk about a "developer [who has] mismanaged the
Back button")

> Removing a feature that's
> intrinsically broken is absolutely the correct use of the standards
> process.

I'd add however that replacing a frameset with iframes doesn't solve
the problem. MSDN (online) correctly (IMO) does *not* use either
frames or iframes, and still works great (using JavaScript, but
Peter's example requires JavaScript too). i'd even say it works better
than Peter's example because the tree state is maintained on the
client-side, which means requests to the server can be cached
efficiently (and additionally are lighter-weight and don't even
require server-side processing)

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

Re: [whatwg] framesets

2009-10-09 Thread Boris Zbarsky


On 10/9/09 12:04 PM, Aryeh Gregor wrote:

  I don't know why back and forward don't work in the browsers I tried
it in


Here's what "copy link location" gives me for a randomly picked link in 
the menu on the left in Firefox:


javascript:parent.frames["detail"].location.replace("infoitem.php?_sess=sess1255105042&id=24");

Here's what it gives me for the little expander widget of one of those 
links:


javascript:parent.frames["tree"].location.replace("infotree.php?_sess=sess1255105042&t=557&toggle=3#557");

Note the replace() calls.

What was that about developers mismanaging the back button?

-Boris

Re: [whatwg] framesets