[whatwg] framesets

[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 <pb at artfulsoftware.com>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 <frameset> or <font> 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 <pb at artfulsoftware.com> <pb at artfulsoftware.com> 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) <table>+<iframe>: 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 <div>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?
>
>
>  C) is definitely a hack. Even worse, it's a Microsoft hack.
> Rather than a hack, it's quite re-inventing the wheel: it takes a
> purely structural element with no specific semantics or behavior
> (<div>) and uses other tools to define the appearance (CSS) and
> behavior (scripting). So, of course, it's a heavy and probably
> overkill application. Basically, it's been quite like migrating MS's
> Document Explorer from the Windows platform to the web platform: it
> works on the web, but it doesn't reuse too much of what web
> technologies already provide.
> B), on the other hand, is *not* a hack at all: using CSS this way for
> these cases is exactly what these CSS properties were made for. Of
> course, the CSS approach fails on the resizing task; and that's were a
> scripting-based hack can come into play; but CSS on itself is a
> legitimate solution for a wide range of use cases, rather than a hack.
> It seems that your use case is not within this range, so the CSS
> solution doesn't work for you; but that's legitimate: this is why we
> are having this discussion, and my hopes are that it will led to the
> best possible solution.
>
>
>
>  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.
>
>
>  I haven't claimed that the removal should make no difference. What I
> have stated is that there is no such removal: Transitional/Strict
> doctypes from HTML4 are being updated and combined into a single spec,
> thus the "version" number is increased, leading to the "HTML5" term.
> The Frameset document type stays untouched. The only reason there
> isn't an "HTML5 Frameset" type is because it would be 100% identical
> to the "HTML4 Frameset" one. There is no point in having two
> "versions" of a spec that are actually the same.
> 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 <frameset> or <font> 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).
>
> Your point on combining HTML5 features with framesets may be
> interesting; but what prevents you from doing so now? The document
> shown on each frame can perfectly be a HTML5 document. Using HTML5
> features inside <noframes> would be quite unadvisable: if a UA can't
> handle frames, would you really expect it to handle stuff like <video>
> or <gauge>?
> That covers frame content, and no-frame content. Is there any other
> place where you might want to use these features? If so, please,
> elaborate (describe which features you'd need, where you'd need to be
> able to use them, and why).
>
> Regards,
> Eduard Pascual
>
> ------------------------------
>
>
> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091011/be425469/attachment-0002.htm>