Frames as Rodney Dangerfield

[MartinRinehart]

They just don't get no respect.

"In the early days of JavaScript, multiframe and multiwindow web
applications were fairly common. Now, web design has turned strongly
against the use of frames (but not inline frames, called <i>iframes)</
i>, and it is less common to see web sites that use interacting
windows." (Flanagan, 5e; footnote, p. 289)

Why?

[Thomas 'PointedEars' Lahn]

Ma************@gmail.com wrote:

They just don't get no respect.

You are not making sense.

"In the early days of JavaScript, multiframe and multiwindow web
applications were fairly common. Now, web design has turned strongly
against the use of frames (but not inline frames, called <i>iframes)</
i>, and it is less common to see web sites that use interacting
windows." (Flanagan, 5e; footnote, p. 289)

Why?

Evidently, Flanagan rarely knows what he is talking about, if that. The
choice of not using frames or iframes has nothing to do with scripting at
all, as since the first day they were supported the `target' attribute of
`a' elements was supported. It is a matter of accessibility and of CSS
emerging about twelve years ago instead.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[Joost Diepenmaat]

Thomas 'PointedEars' Lahn <Po*********@web.dewrites:

Ma************@gmail.com wrote:

>"In the early days of JavaScript, multiframe and multiwindow web
applications were fairly common. Now, web design has turned strongly
against the use of frames (but not inline frames, called <i>iframes)</
i>, and it is less common to see web sites that use interacting
windows." (Flanagan, 5e; footnote, p. 289)

Why?

Evidently, Flanagan rarely knows what he is talking about, if that.
The choice of not using frames or iframes has nothing to do with
scripting at all, as since the first day they were supported the
`target' attribute of `a' elements was supported. It is a matter of
accessibility and of CSS emerging about twelve years ago instead.

You're putting words in Flanagan's mouth. He's absolutely correct that
frames are used a lot less than they used to be and he doesn't talk
about scripting at all in that quote. But you're correct that the main
reason they're not used that much anymore are the accessibility issues
and CSS making inline scrolling elements possible.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[Joost Diepenmaat]

Joost Diepenmaat <jo***@zeekat.nlwrites:

You're putting words in Flanagan's mouth. He's absolutely correct that
frames are used a lot less than they used to be and he doesn't talk
about scripting at all in that quote.

I mean, he's not making any statement relating scripting to frames,
he's just saying that at the time javascript became popular, frames
were too.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[MartinRinehart]

Can someone elaborate on the accessibility issues?

I've just done: http://ClintonBushCharts.org with extensive nested
frames. I've been very pleased with the result. Would I have been
smarter to use CSS instead of frames?

Flanagan is the single book recommended in the JS FAQ. Does[n't] he
deserve this?

I've also read that you should avoid frames as they "break" search
crawlers. As I see it, the issue is using JS v. using <a href...and
isn't really related to frames. Am I missing something on this, too?

Thanks!

[Thomas 'PointedEars' Lahn]

Ma************@gmail.com wrote:

Can someone elaborate on the accessibility issues?

You should try a newsgroup where this is on-topic instead.

I've just done: http://ClintonBushCharts.org with extensive nested
frames.

Evidently, you hardly know what frames are, nor how to write HTML. You have
declared HTML 4.01 Frameset and did not use a single `frameset' or `frame'
element in the homepage tag soup^W^W document. In the document you are
referring to you are placing invalid declarations for comments above the
DOCTYPE declaration, triggering Quirks/Compatibility Mode. You are using
CSS lengths in the value for the `rows' and `cols' attributes of `frameset'
elements. And I could go on like this for hours.

<http://validator.w3.org/>

(I really wonder which language standards committees you want to have served
on anyway; hopefully nothing Web-related.)

I've been very pleased with the result.

That must be because you have never tested it with different user agents and
font sizes, for example. So your visitors, among them me, are not pleased
at all. Remember: The worm must be tasty for the fish, not for the
fisherman. But as the for the latter, you don't even make an average
fisherman yet.

Would I have been smarter to use CSS instead of [tables]?

Most definitely.

Flanagan is the single book recommended in the JS FAQ. Does[n't] he
deserve this?

Search the archives.

I've also read that you should avoid frames as they "break" search
crawlers. As I see it, the issue is using JS v. using <a href...and
isn't really related to frames. Am I missing something on this, too?

Obviously, but this is off-topic here as well.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Joost Diepenmaat]

Ma************@gmail.com writes:

Can someone elaborate on the accessibility issues?

The basic problem is that it's hard to navigate frames (and see when
frames are loaded with new content) when you've got a screen reader or
some similar program (or a braille machine). "Normal" visual browsers
show blocks of content in spatial relations, but browsers (or browser
extensions) catering to blind people have a hard time to make frames
easy to use, and it's in general best to have the document's structure
reflect the way you'd want to read it from top to bottom (and frames
subvert this by changing the overall content on the fly).

Not that javascript and/or iframes are much better in this regard. The
main problem seems to be that replacing/switching parts of a page is a
technique that's hard to make accessible to all users. Especially
users that can only read about one line of text at a time. It may be
better for those users to have a system that's based on "primitive"
full-page reloads. Provided they can navigate quickly to the sections
they're interested in (and leave out all the unnessary iframe / frame
/ div replacement / ajax stuff).

I've just done: http://ClintonBushCharts.org with extensive nested
frames. I've been very pleased with the result. Would I have been
smarter to use CSS instead of frames?

It would be nice if it worked with javascript disabled. Especially
since it looks like most of the scripting does the equivalent of the
<a target="..."attribute.

Flanagan is the single book recommended in the JS FAQ. Does[n't] he
deserve this?

Flanagan's book is only the best book that handles most browser
scripting. It's far from infallible, and contains some information
that's IMO pretty misleading, when you get down to the details. But I
think PointedEar's comment was uncalled for.

I've also read that you should avoid frames as they "break" search
crawlers. As I see it, the issue is using JS v. using <a href...and
isn't really related to frames. Am I missing something on this, too?

Any search crawler worth its salt should handle frames. The main
problem as I hinted above is accessibility for people with visual
handicaps.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[Gregor Kofler]

Ma************@gmail.com meinte:

Can someone elaborate on the accessibility issues?

I've just done: http://ClintonBushCharts.org with extensive nested
frames. I've been very pleased with the result. Would I have been
smarter to use CSS instead of frames?

There's not a single frame on this page.

and - perhaps more important -

Where's the JS relevance?

Flanagan is the single book recommended in the JS FAQ. Does[n't] he
deserve this?

Why should this be relevant for a pure markup question?

I've also read that you should avoid frames as they "break" search
crawlers. As I see it, the issue is using JS v. using <a href...and
isn't really related to frames. Am I missing something on this, too?

More adequate newsgroups exists for this topic.

Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

[Gregor Kofler]

Gregor Kofler meinte:

There's not a single frame on this page.

Ah I see - the following pages have framesets. But the markup... atrocious.

Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

[MartinRinehart]

To all my apologies for not starting this way:

If you use frames you stop having "the global namespace" and you start
having multiple global namespaces (which means the word "global" is,
at best, somewhat misleading). Therefore, the question of use/non-use
of frames has a critical impact on your JavaScript.

OFF TOPIC

I am one of a large class of people who wish to use the WWW to
communicate with others but who are not, and do not aspire to be,
professional web developers. W3C consistently ignores us.

And the validator ignores the spec. "White space (spaces, newlines,
tabs, and comments) may appear before or after each section." ( 7.1
http://www.w3.org/TR/REC-html40/struct/global.html ).

[Henry]

On Jul 7, 4:00 pm, [e-mail] wrote:

To all my apologies for not starting this way:

If you use frames you stop having "the global namespace"

The term 'namespace' has no technical meaning in javascript (it does
not appear at all in the language's specification), and so there is no
"the global namespace" as such.

(For those who would like to argue that the term 'namespace' is
sufficiently unambiguously defined and used that it can be used in
relation to javascript even if no specified meaning exists for
javascript, consider how very different differing approaches to
namespaces are (think XML namespaces)).

and you start having multiple global namespaces

You start to have multiple global objects.

(which means the
word "global" is, at best, somewhat misleading).

That probably depends on where you observe from.

Therefore, the question of use/non-use of frames
has a critical impact on your JavaScript.

Certainly using frames can add a layer of complexity to scripts.

OFF TOPIC

I am one of a large class of people who wish to
use the WWW to communicate with others but who are
not, and do not aspire to be, professional web
developers. W3C consistently ignores us.

Does something make you think that the W3C pays any attention to
people who are "professional web developers"?

And the validator ignores the spec. "White space (spaces,
newlines, tabs, and comments) may appear before or after
each section."
( 7.1http://www.w3.org/TR/REC-html40/struct/global.html).

If that were true then you would be in a position to demonstrate its
truth. Otherwise nobody will be in a position to correct your
misconceptions and you will then just be wasting bandwidth.

[webbugtrack]

One other note on frames (vs. iframes).

You can't float content from one frame over another, so if you have a
calendar widget or similar, it will always be trapped within a frame.
If you were to use iframes instead, this limitation is removed.

[Thomas 'PointedEars' Lahn]

we*********@gmail.com wrote:

One other note on frames (vs. iframes).

You can't float content from one frame over another, so if you have a
calendar widget or similar, it will always be trapped within a frame.
If you were to use iframes instead, this limitation is removed.

It is not.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16