|
Posted by Harlan Messinger on November 1, 2004, 10:49 am
Please log in for more thread options
> wrote:
>
> >And whilst we're at it:
> >http://www.htmlhelp.com/design/frames/whatswrong.html
>
> Out of interest, (and seriously-not "frames suck") why not frames? (A
> more up to date view rather than one written 7 years ago)
If the reasons were good seven years ago, why, to your knowledge, wouldn't
they be good now? All the old reasons for not operating heavy equipment
while drunk are still good, aren't they? :-)
>
> The only really valid argument I can see on the above page is that
> lots of work would need to be duplicated to deal with the NOFRAMES
> scenario. (How many browsers these days don't deal with Frames?)
>
> If a web page writer tests their design in several common browsers and
> at the common screen resolutions (as everyone does yes?), and the
> frames display as intended, why not use frames?
Inability to bookmark a page.
If someone *does* get the URL for a page in the main content frame and
passes it to others, when they use it they'll see that page only, without
the frames, and will therefore be unable to browse the rest of your
site--which you would probably like them to be able to do.
Indexability by search engines.
One that's newer than reasons from seven years ago: because they're not
supported in strict HTML.
>
> It's easy enough for a framed page to call up the frameset,
I don't know what this means.
> so a
> search engine hit on a page can easily be dealt with.
How does the search engine know your page is there in the first place? The
spiders that index pages don't support frames. They'll only see what's
inside the NOFRAMES element.
>
> If there's a W3C doctype set for frames, then surely they can't be
> that bad, huh?
The frameset DTD is a modified version of the transitional DTD and, like the
transitional DTD, covers deprecated features that aren't in the strict DTD
for the purpose of supporting legacy documents. Frames are one of those
features.
|
|
Posted by Malcolm Dew-Jones on November 1, 2004, 2:03 pm
Please log in for more thread options
me (me@no.where.com) wrote:
: Out of interest, (and seriously-not "frames suck") why not frames?
Speed of display.
Frames are commonly used for layout, and each "page" is actually a
complete new frame set. Each such "page" typically requires four or even
five downloads instead of just one.
The problem is that the time to serve a page is not just based on
the volume of data. There is additional overhead for each request.
For non-large pages the speed of the screen update depends just as
much on the number of requests as on the total volume of data.
A non-frame page would transfer all the data in a single request.
A typical frame page will transfer the same data in four or even five
requests (the frameset and three or four frames).
Therefore these frame based pages can be slower to display.
|
|
Posted by Chris Morris on November 1, 2004, 3:31 pm
Please log in for more thread options > wrote:
> >And whilst we're at it:
> >http://www.htmlhelp.com/design/frames/whatswrong.html
>
> Out of interest, (and seriously-not "frames suck") why not frames? (A
> more up to date view rather than one written 7 years ago)
Frames haven't changed at all in the last seven years. The way
browsers deal with frames has barely changed in the last seven
years. None of the problems in that article have gone away, but
there's several it doesn't mention (see below).
> The only really valid argument I can see on the above page is that
> lots of work would need to be duplicated to deal with the NOFRAMES
> scenario. (How many browsers these days don't deal with Frames?)
Rather more than you think. Several don't deal with them *well*, and I
don't know of any mainstream search engine that goes for anything
other than the <noframes> content.
If you don't consider the lack of URL/page relationship (which breaks
bookmarking and in some browsers the back button too) a problem then
you should. It may not be a problem for the author but it certainly is
for many users. This is solvable while keeping frames, but it's a
third chunk of work per page.
Other problems not mentioned in that article:
Printing doesn't work particularly well with frames. It's
unpredictable at best, refuses to print the right frame *at all* at
worst. No real workarounds.
Navigation doesn't change to indicate where you are, so you get
circular links and other problems. Again, this is solvable if you
apply the fix to get the URL/page relationship, but it further
increases the amount of work needed to get the frames to work as well
as the normal page model they replace.
Effectively, to avoid most of the problems with frames you need to
write a separate frameset, navigation document, content document and
noframes element for each page. This is considerably more work
> If a web page writer tests their design in several common browsers and
> at the common screen resolutions (as everyone does yes?)
Do they? The impression I get is that most websites *may* get tested
in IE, if the author is having a good day.
I test in lots of browsers, but generally I keep the screen resolution
at 1024*768 where it belongs (on this monitor for this user). The
*canvas width*, the important number, is currently about 820px but
gets tested across a wide range.
> and the frames display as intended, why not use frames?
Not that web stats are particularly accurate, but here's the top user
agent string list from one server I maintain for October, and whether
they support frames.
1) IE. [Yes]
2) Googlebot. [No]
3) Mozilla. [Yes]
4) Msnbot. [Not as far as I know]
5) Firefox [Yes]
6) Opera [Yes or no, depending on what it's running on]
7) WWLib [No idea what this is. Maybe it does, maybe it doesn't]
8) Netscape. [Yes]
9) Slurp [Not as far as I know]
10) Safari [Yes]
If we take out the four above that are (probably) search engines [1] in favour
of other browsers, then onto the end of the list:
11) Konqueror [Yes]
12) Lynx [Depends on version, but not particularly well when it does]
13) Galeon [Yes]
14) w3m [Yes, but poorly]
[1] I'm assuming WWLib is some sort of spider. If anyone knows that it
isn't, fine, my points stand either way.
How many of those common (top-10) browsers have you tested in? How
many of those search engines have you tested the display in?
> It's easy enough for a framed page to call up the frameset, so a
> search engine hit on a page can easily be dealt with.
It can call up the frameset, but can it call up the frameset on the
right page? You need to fix the URL problem, which you didn't consider
important.
> If there's a W3C doctype set for frames, then surely they can't be
> that bad, huh?
There's a W3C doctype for HTML 3.2, but it's generally agreed that a
lot of things in that are bad. Just because the W3C defines a way to
use something doesn't mean that it's necessarily good for general use
[2].
[2] In carefully selected specific uses, frames can be useful. There's
a thread from fairly recently trying to find some examples if you look
at the archive. But in general use on an average website? No.
--
Chris
|
|
Posted by Alan Wood on November 2, 2004, 2:41 am
Please log in for more thread options
> I don't know of any mainstream search engine that goes for
> anything other than the <noframes> content.
Google and Yahoo! both fully index the content of frames.
Try this search (with the quotes): "5-acetyl-8-quinolinol"
The results include indexes of IUPAC names that exist only as part of
a frameset. The search string does not exist within the <noframes>
content.
--
Alan Wood
http://www.alanwood.net (Unicode, special characters, pesticide names)
|
|
Posted by brucie on November 2, 2004, 8:56 pm
Please log in for more thread options In comp.infosystems.www.authoring.html Alan Wood said:
>> I don't know of any mainstream search engine that goes for
>> anything other than the <noframes> content.
> Google and Yahoo! both fully index the content of frames.
> Try this search (with the quotes): "5-acetyl-8-quinolinol"
>
> The results include indexes of IUPAC names that exist only as part of
> a frameset. The search string does not exist within the <noframes>
> content.
first result is this page:
http://www.hclrss.demon.co.uk/quinacetol.html not a framed page
second result is this page:
http://www.hclrss.demon.co.uk/index_iupac_frame.html not a framed page
the second page tells me to go to another page if the navigation is
missing and that page tells me a lot of babble including a link to the
"browser requirements" for the site.
the only "browser requirements" the site should have is to work with the
visitors browser without making them jump through hoops to get to the
content. it does not.
very poor design. is it yours? i'd like to give you a good smack in the
head and tell you to wake up to yourself.
--
the facts and opinions expressed by brucies
l i t t l e v o i c e s
are not necessarily the same as those held by brucie.
|
| Similar Threads | Posted | | BGCOLOR only in Opera, not other browsers (valid page) | May 4, 2008, 1:38 am |
| problems getting valid HTML out of PHP | September 17, 2004, 6:26 pm |
| valid html for framesets | February 13, 2005, 10:25 am |
| Valid HTML Tutorial | December 6, 2005, 12:12 pm |
| Inserting MP3 into Valid HTML | September 24, 2008, 8:03 pm |
![]() valid (X)HTML? | December 17, 2007, 6:31 pm |
| Unrecognized file format prolem with valid html, please help! | November 9, 2004, 6:55 pm |
| Seemingly-simple valid HTML renders diff in FF1.0, IE6 | January 25, 2005, 12:04 pm |
W3C Validator error?
is valid for doctype HTML 4.01 Strict | April 21, 2005, 12:46 pm |
| legality/practicality of nesting complete, valid HTML pages | November 14, 2008, 1:11 am |
|
XML Sitemap