Peter,<br><br>Thanks for the clarification, I think I have a little better understanding now.<br><br>(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 <tree> tag? I guess my confusion lies in why frames & framesets are being discussed at all.<br>
<br>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?<br>
<br>I was envisioning a <tree> 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?<br>
<br>Mike Ressler<br><br><br><div class="gmail_quote">On Mon, Oct 12, 2009 at 12:01 PM, Peter Brawley <span dir="ltr"><<a href="mailto:pb@artfulsoftware.com">pb@artfulsoftware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
Mike,<div class="im"><br>
<br>
>Can you explain what you mean by "A DB row is a tree node and it
must
be possible <br>
>to block bookmarking of
such rows." a little more? From my understanding, a developer <br>
>could
accomplish this with an onclick handler and some URI arguments, but it
seems like <br>
>you're focused on the browser itself preventing the
bookmarking of the link.<br>
<br></div>
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.<br>
<br>
Yes I agree there are lots of ways to block data bookmarking.<br>
<br>
PB<br>
<br>
------<br>
<br>
<br>
Mike Ressler wrote:
<blockquote type="cite"><div><div></div><div class="h5">Peter, <br>
<br>
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.<br>
<br>
What would preventing bookmarking by the browser accomplish that an
onclick handler that rewrites the URI of the link not accomplish?<br>
<br>
Mike Ressler<br>
<br>
<div class="gmail_quote">On Mon, Oct 12, 2009 at 11:21 AM, Peter
Brawley <span dir="ltr"><<a href="mailto:pb@artfulsoftware.com" target="_blank">pb@artfulsoftware.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
Ian,
<div><br>
<blockquote type="cite"><span></span><span>> </span>I quoted
Andrew Fedoniouk <br>
<span>> </span>(<a href="http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html" target="_blank">http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html</a>),
<br>
<span>> </span>"There are use cases when
frames are good. As an example: online (and <br>
<span>> </span>offline) help systems ...
In such cases they provide level of usability <br>
<span>> </span>higher than any other
method of presenting content of such type."<br>
<span>> </span><br>
<span>> </span>I've not seen a
counterexample. Have you?<br>
</blockquote>
> I believe Andrew's statement to be incorrect. <br>
<br>
</div>
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. <br>
<div><br>
> search engines can't index into them (search is a critical part of
help<br>
> systems), pages in them can't easily be bookmarked
<br>
<br>
</div>
A DB row is a tree node and it must be possible to block bookmarking of
such rows.
<div><br>
<blockquote type="cite">Supposing that someone can produce
examples,
the argument for removing <br>
frames from HTML5 becomes: "frameset has been in HTML till now, /but is
<br>
being removed because we do not like it/. If you insist on such use <br>
cases, re-architect them." That's a misuse of standards.<br>
</blockquote>
>That's how we roll here. :-)<br>
<br>
</div>
So I see. It's appalling.<br>
<br>
PB<br>
<br>
-----<br>
<br>
Ian Hickson wrote:
<blockquote type="cite">
<div>
<div>
<pre>On Thu, 8 Oct 2009, Peter Brawley wrote:
</pre>
<blockquote type="cite">
<pre>According to <a href="http://www.w3.org/TR/2009/WD-html5-diff-20090825/" target="_blank">http://www.w3.org/TR/2009/WD-html5-diff-20090825/</a>, "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
(<a href="http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html" target="_blank">http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html</a>),
"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?
</pre>
</blockquote>
<pre>Except for resizing, anything you can do with framesets, you can do better
with <iframe>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:
<a href="http://www.artfulsoftware.com/infotree/mysqlquerytree.php" target="_blank">http://www.artfulsoftware.com/infotree/mysqlquerytree.php</a>
...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 <iframe>s, other techniques exist to get similar results,
e.g. AJAX. The use case covered by <frameset> 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. <iframes>, on the other hand, are very easy to migrate to.)
On Fri, 9 Oct 2009, Peter Brawley wrote:
</pre>
<blockquote type="cite">
<pre>W3C's job is to enable, not function like a commissariat.
</pre>
</blockquote>
<pre>This isn't the W3C.
On Fri, 9 Oct 2009, Peter Brawley wrote:
</pre>
<blockquote type="cite">
<pre>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.
</pre>
</blockquote>
<pre>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:
</pre>
<blockquote type="cite">
<pre>The big difference is that <iframe>s can be used in good ways, framesets
essentially can't.
Another reason do deprecate <frameset> but not <iframe> is that we don't
need *two* ways to make poorly behaving pages.
</pre>
</blockquote>
<pre>Indeed.
On Fri, 9 Oct 2009, Peter Brawley wrote:
</pre>
<blockquote type="cite">
<pre>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.
</pre>
</blockquote>
<pre>That's how we roll here. :-)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>What'd be the point of keeping two sources of issues when one can be
enough to cover all use-cases?
</pre>
</blockquote>
<pre>If your premiss is correct, backward compatibility.
</pre>
</blockquote>
<pre>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:
</pre>
<blockquote type="cite">
<pre>Why relegate a perfectly sound use case to a cul-de-sac?
</pre>
</blockquote>
<pre>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. <iframe>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:
</pre>
<blockquote type="cite">
<pre>It's not your brief to decide what's beneficial for a client.
</pre>
</blockquote>
<pre>Actually, it sort of is.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>It conflicts with expected behavior.
</pre>
</blockquote>
<pre>It does not conflict with what these users expect.
</pre>
</blockquote>
<pre>Framesets actually do conflict significantly with what most users expect;
that's one of their problems.
</pre>
<blockquote type="cite">
<pre>Framesets are part of the current HTML standard and should remain.
</pre>
</blockquote>
<pre>Actually framesets were deprecated in 1998. They've been on the chopping
block for over ten years now. Their use is _so_ discouraged in HTML4 that
they are not even included in the Transitional DTD, they are relagated to
their own third-tier DTD.
On Fri, 9 Oct 2009, Peter Brawley wrote:
</pre>
<blockquote type="cite">
<pre>I quoted Andrew Fedoniouk
(<a href="http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html" target="_blank">http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html</a>),
"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?
</pre>
</blockquote>
<pre>I believe Andrew's statement to be incorrect. I would argue that the
usability of help sites based on <frameset>s is horrible. For example,
search engines can't index into them (search is a critical part of help
systems), pages in them can't easily be bookmarked and URLs to them can't
be shared with other people (another critical part of help systems), and
using the "open in new tab" feature on index pages of help systems that
use framesets ends up breaking the frameset, making browsing multiple
aspects in parallel difficult.
On Sat, 10 Oct 2009, tali garsiel wrote:
</pre>
<blockquote type="cite">
<pre>1. Tabs and tree menu navigation is very common in web applications. Do
you agree with that assumption?
</pre>
</blockquote>
<pre>Tabs are a media-specific presentation issue, and don't belong in HTML.
Tree menu navigation is a use case we need to fix anyway, and will
probably do so in the next version of HTML. (We were going to do it in
HTML5, but had to punt because we couldn't get the detailed nailed down.
It's a hard thing to get right.) However, that's independant of frames.
The problem exists regardless of what the look is, one frame or many.
</pre>
</div>
</div>
<pre><hr size="4" width="90%"><div>
No virus found in this incoming message.
Checked by AVG - <a href="http://www.avg.com" target="_blank">www.avg.com</a>
Version: 8.5.421 / Virus Database: 270.14.9/2428 - Release Date: 10/11/09 06:39:00
</div></pre>
</blockquote>
</div>
</blockquote>
</div>
<br>
</div></div><pre><div><div></div><div class="h5">
<hr size="4" width="90%">
No virus found in this incoming message.
Checked by AVG - <a href="http://www.avg.com" target="_blank">www.avg.com</a></div></div>
Version: 8.5.421 / Virus Database: 270.14.11/2430 - Release Date: 10/12/09 04:01:00
</pre>
</blockquote>
</div>
</blockquote></div><br>