On Oct 13, 2009, at 11:20 PM, Peter Brawley wrote:
Ian,
> Your requirements aren't met by framesets
Eh? Our solution meets the requirement and uses framesets.
You have specified that your requirement is to prevent people from
linking to or bookmarking individual pages inside of frames. Framesets
do not satisfy that requirement. They make it a little more difficult,
but they do not prevent it.
> <iframe>s have been demonstrated to work as well as framesets
No-one's been able to point to a working non-frameset solution that
meets this requirement.
Ian posted one, had-written just for you, which you dismissed without
giving any reason.
>, and, well, framesets suck.
Unargued, subjective.
Framesets suck because they combine both layout and embedding
semantics into one syntax, which give them much less layout
flexibility than using CSS. Anything you can do with framesets (except
resizing), you can do with iframes and CSS. However, there are lots of
things you can do with iframes and CSS that you cannot do with
framesets. Framesets are a completely different language than HTML;
you cannot use framesets and any other content elements in the same
document. This means that you are forced to, for example, use a frame
for the header of your page, which may cause a scrollbar to appear if
you don't allocate enough space, rather than just putting the header
in the page directly and using iframes to include the other pages.
>I agree that there's
>lots of legacy content using framesets; that's why HTML5 defines
how they
>should work (in more detail than any previous spec!).
?! According to http://www.html5code.com/index.php/html-5-tags/html-5-frameset-tag/
, "The frameset tag is not supported in HTML 5."
That is not the draft HTML5 spec. I'm not sure what that is, but as
far as I know, it has no official affiliation with either the W3C or
the WHATWG. Try: http://whatwg.org/html5 or more specifically:
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#frames-and-framesets
The HTML5 spec includes two types of conformance requirements;
conformance requirements for authors (or other producers of HTML), and
conformance requirements for user agents (browser and other consumers
of HTML). It is non-conforming in HTML5 to produce documents with
framesets, however a conforming user agent must parse and process them
consistently with the spec.
>The only thing that is easier with framesets than otherwise appears
to be
>resizing, which I agree is not well-handled currently.
Unsubstantiated claim absent a working example of the spec
implemented without framesets.
Did you take a look at Ian's example?
http://damowmow.com/playground/demos/framesets-with-iframes/001.html
>As noted before,
>though, that's an issue for more than just frames; we need a good
solution
>for this in general, whether we have framesets or not. Furthermore,
that's
>a styling issue, not an HTML issue.
For those who have to write or generate HTML, that's a distinction
without a difference.
PB
-----
Ian Hickson wrote:
On Tue, 13 Oct 2009, Peter Brawley wrote:
I don't know if there are pages that do this (and I sure hope
none are
using <table> for it!), but the lack of an existence proof is not
proof of the lack of existence.
Of course. The point is if no-one can point to a working iframes
solution, ie, to an instance of them actually being preferred, the
claim
that iframes provide a preferable alternative is simply not
credible, to
put it mildly.
At this point I don't really understand what you want framesets
for. Your
requirements aren't met by framesets, <iframe>s have been
demonstrated to
work as well as framesets, and, well, framesets suck. I agree that
there's
lots of legacy content using framesets; that's why HTML5 defines
how they
should work (in more detail than any previous spec!). But that
doesn't
mean we should encourage them.
The only thing that is easier with framesets than otherwise appears
to be
resizing, which I agree is not well-handled currently. As noted
before,
though, that's an issue for more than just frames; we need a good
solution
for this in general, whether we have framesets or not. Furthermore,
that's
a styling issue, not an HTML issue.
No virus found in this incoming message.
Checked by AVG -
www.avg.com
Version: 8.5.421 / Virus Database: 270.14.13/2432 - Release Date:
10/13/09 06:35:00
