It is currently Tue May 21, 2013 12:05 pm Advanced search
JAB Creations wrote:A site with music shouldn't be forced to have it's music be played in a separate tab or window. That's personal preference and horridly bad design just as pop-ups are. Not even considerable reasons to drop frames.
zcorpan wrote:If you want HTML5 to allow framesets, then you'll probably have to provide use cases for which using <iframe> or other means are not sufficient.
HTTP was designed with each request being completely independent and stateless, so that design does make sense from that point of view.
While it is fully possible to create those interfaces (in a better way, IMO) with iframes, css (overflow:auto), ajax, etc.,
if you really want frameset so bad,
what's preventing you from embedding html 5 documents in a frames page?
pzbrawl wrote:what's preventing you from embedding html 5 documents in a frames page?
There's too much to do to waste time re-architecting something that has been working just fine for years, just because some W3C people got religion about frames.
Uh... if you don't want to bother with HTML 5 at all, why complain about it in the first place? Nobody is forcing you to rework anything.
JAB Creations wrote:lyosha, we're removing anchors from HTML5; you can still use them on your site, but it won't be valid.
Is the "can be widened" essential to your use case? If not, it seems it should be possible to have the header be part of the page, the left frame be an <iframe> and the right frame be an <iframe>, too, with CSS to give them the right size and position.pzbrawl wrote:Here are two.
Use case #1:
We use a frameset in a web browser for maintenance of trees in (MySQL) databases. For an example of what it looks like, look at online MSDN documentation. We do NOT wish to have to host this on a Windows server.
The trees typically have thousands of items. Top frame has a header and a search control. Below it, the left frame scrolls the tree autonomously, cannot be closed, can be widened. Within it, user may open up or close the whole tree or part of it, may select/create/edit/delete,cut/paste nodes. Right frame shows detail content for the tree node currently selected in the left frame, and offers editing of that content.
What aspects?pzbrawl wrote:Use case #2:
A questionnaire with hundreds of items, live header info, summary stats and ancillary info (including help) in one frame, independently scrolling question/answer controls in the other.
This might be somewhat doable with <iframes> but it appeared to us we would lose some desirable aspects of our interface.
There has always been things in HTML that have been declared as "bad" in the HTML specs. For example, the IIIR HTML draft declares the <plaintext> element as "bad". Framesets were declared as "bad" in the HTML spec that introduced them, too.pzbrawl wrote:A general comment: Willingness to declare certain web interfaces "bad" strongly suggests that a weird nanny/religious mentality has taken hold--inappropriately--in the W3C community. It echoes previous codiong "religions" (eg dynamic typing used to be "bad"; so did non-OO coding). There are no "bad" interfaces. Interfaces do and don't meet their requirements, is all.
Users browsing this forum: No registered users and 1 guest