[whatwg] framesets

[Eduard Pascual]

On Sun, Oct 11, 2009 at 6:31 PM, Peter Brawley <pb at artfulsoftware.com> 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 <frameset>, <table>+<iframe>, 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 <tables>+<iframes> alone would meet
your requirements. I clearly stated that such approach would miss the
resizing requirement, and that it could be hacked through scripting.
<iframe> is enough to display frames, wherever you want on a document
(after all, that's what it is for). <table> gives you the layout tools
provided by <frameset> (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 <frameset> is currently the best solution
for the use case you provided.
It seems that <frameset> covers most requirements. Is there any
requirement not covered by this solution?
<frameset> is not being removed from HTML. It's just not being updated
because there was nothing to add to it, so it stays the same.
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? What did you want to achieve when you started this thread?
What is your goal in this discussion? Until you provide a clear answer
to that, we are basically stuck.
I have been trying to extract useful stuff (such as use-cases and
requirements) from you mails; but as long as there isn't a proposal to
discuss, there is no point in discussion. Because of this, I'll
abstain from posting in this discussion until there is something to
actually discuss.

Regards,
Eduard Pascual

[1] http://www.google.com/search?q=HTML+resizable+table

PS: BTW, my name is Eduard, not Edouard. I'd appreciate if you could
avoid mistyping it. Thanks.