Frames and People With Napoleanic Issues >>

Hello All,

My favorite part about his list is when some amateur author of HTML and a
"standards hobbyist" attempts to speak on behalf of the entire world communicating
via markup language. Those folks are the best, because I laugh my tail off every
time you post. Keep up the good work.

As for frames, you can deprecate them, hide them under your bed, put them away in
the closet, or bury them in the end zone with Jimmy Hoffa, and I'll tell you what
-- people are still going to use them. Maybe not everyone, but there is still a
use for them.

Now, I think we can all agree that we've seen a misuse of frames. However, I am
currently involved with one major media company and a start-up, and I have seen a
genuine use for being able to affect one section of a page but not the others, and
the best way to do that now is frames. You can cheer when they change the
standards, and you can pull out your rule book and explain to me in 46 different
ways how rule 12345 specifically states how "you got picked on in high school and
still can't get over it", but we need some sense to reign here.

Perhaps there can be some style attribute that will allow the client to
differentiate between static and dynamic elements of a page. Coming from a
programming perspective, I can see how that is going to be extremely difficult.
Until someone comes up with a better way to import dynamic data into a page with
both static and dynamic elements, we people in the real world are going to
continue to use frames and any browser that moves to support them, and shuts a
user out from his or her favorite site or function is not going to remain popular
for long. (To vendors on this list) To blindly drop your products' ability to
support frames is just going to allow some little guy to come in and scoop up an
unfilled niche (maybe someone like me will write a browser for free and release it
open source if you do), and with all the problems the big guys have supporting
stuff now, I don't see them being able to do that.

If there is a better way and it is just not publicized, then by all means, share
it with us... That is, the people who actually develop  using HTML instead of
praying to an obscure section in a manual (that someone wrote for a trial run of a
first of its kind language).

Also, I would like to ask a few of the people on this list (you know who you are)
to stop condescending to some of the others on the list who are helping to develop
this standard. I understand and follow the discussion on this list, and I have no
trouble keeping pace with your discussions, but a) sometimes you sound ridiculous
when you get into a semantic pissing contest - especially when you do nothing to
propose a resolution to a style/tag/attribute situation, etc. and b) you alienate
some entire areas of the development process, which probably isn't a good thing
when you are developing a language that communicates WORLDWIDE. Just make your
point, and move on please.If you need to use specific language, then use it, but
don't try to sound like you know something we don't because there are those of us
out here that you just aren't fooling. This all really isn't so complicated, so I
hope you'll take this moment and get over it.

One more thing, I'd like to propose a tag... <rant> </rant> so we can enclose all
of our rants that will be filtered out by people who choose to filter them.

Thanks. If anyone else was wondering, there <i_really_mean_it> are  real people on
this list.</i_really_mean_it>
Yes, I said it. Stop taking yourself so seriously and start doing things to help
this world out if you are involved in this process.

-Plain Old Frank-
#########################################
#####With no pompous signature file.#####
#########################################



John Whelan wrote:

> G. James Berigan writes:
> > Ann Navarro <ann@webgeek.com> wrote:
>
> >> That said, it still has no bearing on whether or not XHTML 1.1, a next
> >> generation spec twice removed from HTML 4.0(1) should or should not contain
> >> Frames in it's core.
>
> > HTML 4 already does not contain frames in its core.  There is zero frames
> > support in the Strict DTD.  Noframes markup in a Frameset document is
> > validated as Transitional markup with no option to validate it as Strict.
>
> > FRAMES ARE DEPRECATED IN HTML 4!  THEREFORE THEY CAN BE DROPPED ENTIRELY
> > FROM ANY SUCCESSOR!
>
> It's a bad sign when the tone of the discussion has been reduced to
> shouting.  Since everything appearing in the Transitional but not
> Strict DTD *except* TARGET and NOFRAMES is explicitly indicated in the
> spec as being deprecated, and since
> <http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#h-7.2>
> says
>
> "The HTML 4.01 Strict DTD includes all elements and attributes that
> have not been deprecated or do not appear in frameset documents."
>
> it sounds to me like the W3C was deliberately leaving the question of
> frames' status open by dividing HTML4 into three categories: Strictly
> Validating Stuff, Deprecated Stuff and Frame Stuff.  At any rate, I
> think it's quite a stretch to look at the spec and declare frames to
> be deprecated without more knowledge of the W3C's thinking.
>
> Unlike most items deprecated in HTML4, frames cannot be replaced in
> any obvious way using stylesheets.  In addition to zillions of bad
> uses for frames, there are a few good ones, and since frames are not
> likely to go out of use any time soon, I think the community is better
> served by promoting responsible use of them.  At any rate,
> TARGET="_top" attribute is useful for sites which don't use frames
> themselves but know they're likely to be linked to within someone
> else's frameset.  I was once in that situation with a site I linked
> back to, meaning that I could not use the Strict DTD if I wanted to
> avoid nesting this site's frameset.
>
> Incidentally, the fact that Frames don't appear in HTML 3.2 does not
> rule out their being deprecated.  For instance, the S element was new
> in HTML 4.0, but deprecated at the same time.
>
>                                         John T. Whelan
>                                         whelan@iname.com
>                                         http://www.slack.net/~whelan/