By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,207 Members | 1,028 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,207 IT Pros & Developers. It's quick & easy.

Alternative to Frames

P: n/a
What would be a good alternative to using frames? I need something
that will section my webpage into two halves and can change both
frames on a single click.

Thanks in Advance,
Tammy
Jul 23 '05 #1
Share this Question
Share on Google+
20 Replies


P: n/a
Previously in comp.infosystems.www.authoring.html, Tammy
<ta*****@yahoo.com> said:
What would be a good alternative to using frames?


*Not* using frames.
http://butterflies.usenetshit.info/

--
Mark Parnell
http://www.clarkecomputers.com.au
Jul 23 '05 #2

P: n/a
On 17 Nov 2004 19:19:10 -0800, Tammy <ta*****@yahoo.com> wrote:
What would be a good alternative to using frames?
Anything else, except maybe Flash. A hammer to the gonads is an
improvement over frames.
I need something
that will section my webpage into two halves and can change both
frames on a single click.


Mark's link to brucie's example yields a good method. Another is to
approach it differently. Using PHP (or SSI, though PHP is probably better
for this) you can include content on the server and have pages that can
give the effect without really having two frames.
Jul 23 '05 #3

P: n/a
"Tammy" <ta*****@yahoo.com> a écrit dans le message de
news:f7**************************@posting.google.c om
What would be a good alternative to using frames? I need something
that will section my webpage into two halves and can change both
frames on a single click.


If you're asking for an alternative :

- to include the same content on multiples pages
then a lot of inclusion techniques are available, particularly server side
(SSI, PHP, ...)

- for a split layout
you can hardly do it in CSS. Yes, it's a little complicated to make it work
in all browser, but it can be done (using display: fixed and all its hacks,
and overflow)

- not to reload a piece of what is displayed during the user session (for
exemple to keep a session state in some piece of client side code, or don't
reload a very big html content, or specify different cache headers, or
whatever)
no other alternatives than using frames

Jul 23 '05 #4

P: n/a
In article <f7**************************@posting.google.com >,
ta*****@yahoo.com enlightened us with...
What would be a good alternative to using frames? I need something
that will section my webpage into two halves and can change both
frames on a single click.


The alternative depends on why you thought you needed them in the first
place.
There are a few things that only frames can do. For example, my intranet
application needs a top frame because I reload it every minute to check if a
user is logged in (whether they are logged in or not is displayed, so an
"invisible" frame would not work here). I also store other session data in
it. It would be a bad thing to reload a page a person is trying to type in.
;)
Other than that, though, there really isn't much of a use for them. Many web
IDEs, including Frontpage and Dreamweaver, have a template function so that
if you want all your pages to have the same data in them (navigation,
headers, footers, etc), it's easy to manage w/o frames. If you've got any
kind of server-side processing, SSI, PHP, JSP, CGI, and the like can include
files to get the same effect.

Why do you "need" two sections? What is the goal? Sometimes we think we need
something, but in fact, there are other ways to accomplish the goal (we limit
our options by not seeing the big picture or not knowing of alternatives).

--
--
~kaeli~
What's another word for thesaurus?
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 23 '05 #5

P: n/a
On Thu, 18 Nov 2004 07:40:53 -0600, kaeli
<ti******@NOSPAM.comcast.net> wrote:
Why do you "need" two sections? What is the goal? Sometimes we think we need
something, but in fact, there are other ways to accomplish the goal (we limit
our options by not seeing the big picture or not knowing of alternatives).


I concur. Too many sites these days use CMS on the server to generate
pages dynamically, while contents doesn't change that much, and the
site could easily be generated on a host to render a static site,
ready to be uploaded to any web server.

Besides solving the frame issue (all the pages are generated using
templates, hence it's a breeze to add common sections like nav bars),
a static sites renders faster and any web server can be used.

Ralph.
Jul 23 '05 #6

P: n/a
In article <9j********************************@4ax.com>, ra***@nader.org
enlightened us with...

Besides solving the frame issue (all the pages are generated using
templates, hence it's a breeze to add common sections like nav bars),
a static sites renders faster and any web server can be used.


Since discovering Dreamweaver templates, I am now officially spoiled. :)

I can update the menu for my site - on all 300 pages - with one little
click...or, as I get bored with my stuff often, I just change the entire
layout of every page with one click and a little CSS change.

One of the most common uses for frames is navigation. Now, with CSS and
templates, there's just no reason for that at all.

--
--
~kaeli~
Punctuation, capitalization, and grammar are your friends,
and will help people think that you aren't such an ignorant
moron, after all.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 23 '05 #7

P: n/a
I V
On Thu, 18 Nov 2004 07:40:53 -0600, kaeli wrote:
In article <f7**************************@posting.google.com >,
ta*****@yahoo.com enlightened us with...
What would be a good alternative to using frames? I need something
that will section my webpage into two halves and can change both
frames on a single click.


The alternative depends on why you thought you needed them in the first
place.
There are a few things that only frames can do. For example, my intranet
application needs a top frame because I reload it every minute to check if a
user is logged in (whether they are logged in or not is displayed, so an
"invisible" frame would not work here). I also store other session data in
it. It would be a bad thing to reload a page a person is trying to type in.
;)


I don't know that you do need frames for this. There's a javascript
solution at:

http://www.paranoidfish.org/boxes/2002/01/30/

Although it may well not be an issue for an intranet app, I would think
it's generally easier to work round the disadvantages of JavaScript (i.e.,
by making the page work when JavaScript is unavailable) than the
disadvantages of frames.

--
"Get that shit away from me! Your cheap mind-toasting drugs are no good
to me. I am a journalist, damn your ovaries!"
http://www.huh.34sp.com/

Jul 23 '05 #8

P: n/a
On Fri, 19 Nov 2004 08:14:04 -0600, kaeli
<ti******@NOSPAM.comcast.net> wrote:
Since discovering Dreamweaver templates, I am now officially spoiled. :)


I haven't used those yet. Do they let you generated staticly rendered
pages by combining a template and raw pages, like CMS tools do on the
fly, or do you need to insert some DW-specific tags in each page?

Thx
Ralph.
Jul 23 '05 #9

P: n/a
kaeli <ti******@NOSPAM.comcast.net> wrote in message

news:<MP************************@nntp.lucent.com>. ..
Why do you "need" two sections? What is the goal? Sometimes we think we need
something, but in fact, there are other ways to accomplish the goal (we limit
our options by not seeing the big picture or not knowing of alternatives).

--

I'm putting up a genealogy website. I'm dealing with 8 different
branches (4 on my

husband's side and 4 on my side) each of which has multiple pages.
I'm also dealing with

related materials.

The plan was to make is so the user can click on a branch and the toc
(table of contents)

frame would change to display all the individuals in that branch and
the data frame would

display the first page for that branch. Now clicking on a person's
name would bring up

their data in the data frame. Another link at the top would return
the toc frame to the

main list and the data frame to main data page.

Concerning other resources, these I need to break up into states (this
country being a union

of states). The state list would replace the main toc frame.
Clicking a state would

display its available resources in the data frame.

I do know know of any other way to create a toc list to the left with
data to the right

other than using frames. If there is another method I would dearly
love to hear it. Table

do not achieve the same effect. I could make the first page of the
subgroup the toc for

that group and simply have the viewer have to click back and forth
between sub-toc and data,

but that is a hassle for the user and I would prefer to code it so
they didn't have to do

that.

There must be an alternative out there. Any suggestions?

Tammy
Jul 23 '05 #10

P: n/a
On 20 Nov 2004 01:17:19 -0800, Tammy <ta*****@yahoo.com> wrote:
kaeli <ti******@NOSPAM.comcast.net> wrote in message

news:<MP************************@nntp.lucent.com>. ..
Why do you "need" two sections? What is the goal? Sometimes we think we
need
something, but in fact, there are other ways to accomplish the goal (we
limit
our options by not seeing the big picture or not knowing of
alternatives).
I'm putting up a genealogy website. I'm dealing with 8 different
branches (4 on my
husband's side and 4 on my side) each of which has multiple pages.
I'm also dealing with
related materials.

The plan was to make is so the user can click on a branch and the toc
(table of contents)
frame would change to display all the individuals in that branch and
the data frame would
display the first page for that branch. Now clicking on a person's
name would bring up
their data in the data frame. Another link at the top would return
the toc frame to the
main list and the data frame to main data page.


[ 8< ]
There must be an alternative out there. Any suggestions?


It sounds like a very legit reason for using frames, me thinks. But I do
not have a solurion for you problem.

--
Weblog | <http://home.wanadoo.nl/b.de.zoete/_private/weblog.html>
Webontwerp | <http://home.wanadoo.nl/b.de.zoete/html/webontwerp.html>
Zweefvliegen | <http://home.wanadoo.nl/b.de.zoete/html/vliegen.html>
Jul 23 '05 #11

P: n/a
In article <eu********************************@4ax.com>, ra***@nader.org
enlightened us with...
On Fri, 19 Nov 2004 08:14:04 -0600, kaeli
<ti******@NOSPAM.comcast.net> wrote:
Since discovering Dreamweaver templates, I am now officially spoiled. :)


I haven't used those yet. Do they let you generated staticly rendered
pages by combining a template and raw pages, like CMS tools do on the
fly, or do you need to insert some DW-specific tags in each page?


Basically, you make an HTML page. Then, you tell DW that it's a template and
you tell it which parts should be editable (the title, the header, the body,
etc). DW inserts HTML comments to keep track of that. When you make a new
page, you can say it's from a template (or you can apply a template to an
already existing page) and it will generate the page for you. Then you put
content in the editable sections. When you want to change a template, you
change it, then DW asks you if you want to change all docs that use the
template. Saying yes will change everything.

See the source for one of the pages in my sig to see an example of template
comments.

The pages are static content.

--
--
~kaeli~
Practice safe eating - always use condiments.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 23 '05 #12

P: n/a
In article <f7**************************@posting.google.com >,
ta*****@yahoo.com enlightened us with...

I do know know of any other way to create a toc list to the left with
data to the right

other than using frames.


1. Javascript
2. Applet
3. Flash
4. IFrame (slightly better than a full frameset)
5. SSI or other server-side CGI/scripting

Frames are the easiest way to code it for YOU. ;)
There are many other ways to do it, though.

You do need to consider who your users are. For example, if your users tend
to have old browsers, this would be difficult to do with javascript. If they
all have IE5+ or Netscape 6+, it's much easier. If they have old browsers, an
applet would be better, but then you have to worry about JVM issues. Flash
has its own pros and cons, the biggest con being search engine indexing.
Also, being a plugin, some people won't be able to run it or will refuse to
install the plugin. Dial-up users may not like how slow the page renders with
applets or Flash.
If you've never coded a programming language, trying to make a server-side,
dynamically generated page might be too much for you. Since I do code (for a
living), I'd do it this way. It's the best way since it requires nothing
special from your users. They don't have to install anything, they don't have
to have a particular browser, it downloads fast enough for dial-up, etc.
Using iframes is not the best solution by any means, but IMO, that would be a
better compromise if you don't want to code client-side javascript or server-
side dynamically generated pages.

If you've never coded in a programming language before (html is NOT a
programming language; it's strictly a layout mechanism), you're best bets are
either iframes or Flash. Since iframes are free (Flash is not), you may end
up with that.
If you want to give it a go, though, check out javascript for client-side
DHTML and/or PHP for server-side dynamically generated pages.

I could help you with the javascript or PHP if you need.

--
--
~kaeli~
You can't have everything. Where would you put it?
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 23 '05 #13

P: n/a
kaeli wrote:
In article <f7**************************@posting.google.com >,
ta*****@yahoo.com enlightened us with...
I do know know of any other way to create a toc list to the left with
data to the right other than using frames.

1. Javascript


Innaccessible to anyone with JavaScript disabled or unsupported,
including search engines. That would be particularly bad for a table of
contents.
2. Applet
That's a lot of over kill, it would take far too long to load, and not
everyone supports Java.
3. Flash
Flash has many known accessibility issues, however like all the other
options, as long as you provide adequate alternate content, this might
be ok, but I don't recommend it. It's also overkill, and I do not see
how any of these three options are of any use for creating a TOC.
4. IFrame (slightly better than a full frameset)
I'd recommend using <object> instead, but last time I tested, WinXP SP2
decided to show it's ugly face again and claims a text/html document was
a security risk! (Though, it did at least show the alternate content)
5. SSI or other server-side CGI/scripting
This would be the best option. Create your TOC in an include file, and
just include it dynamically with each request. Usually, this is the
most appropriate alternative to frames, though it does add the extra
download to every page. However, as long as you keep the TOC as short
as possible, this shouldn't be too much problem.
Frames are the easiest way to code it for YOU. ;)
There are many other ways to do it, though.

You do need to consider who your users are.
No, you need to write a website that will work adequately for all users,
regardless of their browser. Although it can be good to optomise a site
for the majority of your users, this should not be done at the expense
of a minority.

For example, if your users tend to have old browsers, this would be difficult to do with javascript.
You should cater adequately for older browsers, even if you believe none
of your visitors use them.

If they all have IE5+ or Netscape 6+, it's much easier.
Statistics are not accurate enough to determine that, user agent strings
are not always included, and can be altered. You should optimise for
modern, standards compliant browsers, but provide adequate alternate
content for older browsers and allow the site to degrade gracefully, but
not become inaccessible.

If they have old browsers, an applet would be better,
No, SSI (or other include method) would be better. As I said before, an
Applet for a TOC would be overkill, and I do not see how it is at all
suitable for the problem.
If you've never coded a programming language, trying to make a server-side,
dynamically generated page might be too much for you.
It's not hard to enable SSI, and include a line like this in each file:
<!--#include virtual="/contents.html"-->
html is NOT a programming language;
Correct.
it's strictly a layout mechanism
Incorrect! HTML is not a page layout format, it is a semantic markup
language that has been abused by far too many for that purpose. When
HTML was designed, it was always intended that presentation and layout
be handled by stylesheets of some form. Originally, there were few
presentational elements and attributes, but these were quickly extended
by proprietary extensions, the damage of which we are still recovering
from and will be for a long time to come.
...check out javascript for client-side DHTML...


Officially, there is no such thing as DHTML. It was a marketing term
created by Microsoft to describe its mixture or HTML, CSS, JavaScript
and VBScript. Those technologies are completely seperate, and should be
referred to as such. It's terms like DHTML that cause people to become
confused and think they are all part of the same language.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://SpreadFirefox.com/ Igniting the Web
Jul 23 '05 #14

P: n/a
In article <8_******************@news-server.bigpond.net.au>,
sp***********@gmail.com enlightened us with...


1. Javascript
Innaccessible to anyone with JavaScript disabled or unsupported,
including search engines. That would be particularly bad for a table of
contents.


That depends.
Every solution has pros and cons.
If a banking site can depend on script, so can mine. If users don't want to
enable it, too bad. That is my decision to make. Or the OP's, as the case may
be. The vast majority of users have JS enabled. If you care about others,
great. If I do not, who are you to say I should?

This is merely a debating point. Personally speaking, sometimes I care,
sometimes I don't. It depends on the site, who it is geared for, and so on. I
am well aware UAs for the disabled most often don't support script. If I
needed a site to be accessible, I'd provide alternative content.
It is a very simple thing to make a site index for search spiders.
2. Applet
That's a lot of over kill, it would take far too long to load, and not
everyone supports Java.


Again, that depends on the content and who it is geared for.
I know this group is geared towards www content, but a lot of people who do
personal pages really don't care about the general public. Only the OP knows
if she cares. ;)
3. Flash


Flash has many known accessibility issues, however like all the other
options, as long as you provide adequate alternate content, this might
be ok, but I don't recommend it. It's also overkill, and I do not see
how any of these three options are of any use for creating a TOC.


Then you aren't very creative. Not my problem. *heh*
It's a simple matter to create an entire website in Flash. Whether or not
that's a good idea depends completely on context. It's a horrid idea for a
site for use by the general public. It's fine for intranet sites and personal
pages for family if people have broadband/DSL.
Did you actually read the post this was a reply to? The site is for geneology
for a family. So, it might be meant only for that family. It wasn't clear.
But, if it IS only for family, there is nothing at all wrong with using
things that aren't "recommended" for general internet use.
4. IFrame (slightly better than a full frameset)
I'd recommend using <object> instead, but last time I tested, WinXP SP2
decided to show it's ugly face again and claims a text/html document was
a security risk! (Though, it did at least show the alternate content)


SP2 completely negates any use for the object tag at all for embedded docs,
as you've discovered. Why bother, since you have to provide alternative
content?
5. SSI or other server-side CGI/scripting


This would be the best option.


I think so, too, but many, if not most, html authors are not programmers.

No, you need to write a website that will work adequately for all users,
regardless of their browser.
In YOUR opinion.
I personally don't give a darn if NN4 users can't use my *personal* pages. I
make sure they don't kill the browser with object detection and the like. If
stuff doesn't do anything for them, that's not my problem. The OP has that
option, same as anyone.
You should cater adequately for older browsers, even if you believe none
of your visitors use them.
In YOUR opinion.
I might care about such things for a commercial site. I care not a whit for a
personal pages.
I don't support NN4 on any of my pages, commercial or not. Neither does my
bank, nor most of the other sites I enjoy visiting. Few of our internal apps
support it - the old ones. If it's fine for them to not support NN4, it's
certainly fine for me.
There comes a point when technology stops being supported - for ANY
technology. Browsers included. Microsoft doesn't support Win95 anymore.
Netscape doesn't support NN3 anymore. They may not even support NN4. Solaris
doesn't support old versions of their OS, either.
Do you ask that music companies still make 8-tracks, too?
If they all have IE5+ or Netscape 6+, it's much easier.
Statistics are not accurate enough to determine that, user agent strings
are not always included, and can be altered. You should optimise for
modern, standards compliant browsers, but provide adequate alternate
content for older browsers and allow the site to degrade gracefully, but
not become inaccessible.


Some people, contrary to popular belief, actually do know their users.
Personally.
Again, I realize this group is www-centric, but the OP states specifically
the site is of a personal nature. She may or may not know her visitors. If
she does, she knows what browsers they use. If the site is highly personal,
she may not care if they have old crap.
If they have old browsers, an applet would be better,


No, SSI (or other include method) would be better. As I said before, an
Applet for a TOC would be overkill, and I do not see how it is at all
suitable for the problem.


Then you haven't seen all the menu applets out there. Again, simple to do if
one knows Java. Not everyone does. Nor do all users have a decent JVM,
especially XP users.
It is an option. Not necessarily a great one or one you would choose, but one
nonetheless.
If you've never coded a programming language, trying to make a server-side,
dynamically generated page might be too much for you.
It's not hard to enable SSI, and include a line like this in each file:
<!--#include virtual="/contents.html"-->


It is if your host doesn't support it or doesn't allow you to turn it on
without paying extra, etc.
I certainly didn't see a URL in any of the posts. For all I know, this is
going up on geoshitties.
Also, it WON'T be the same file in every page, at least from my understanding
of what the OP posted. The content of both "frames" would be changing, so
there won't be the same contents regardless of the main document. There will
be a main TOC as well sub-TOCs for each line of people, FWIU.

Officially, there is no such thing as DHTML.


Wow. I must not be doing dynamic html then. I guess I'm just doing pages that
change content on the client-side using javascript based on user action. Oh,
wait...
If it walks like a duck, quacks like a duck, and shits like a duck...
http://www.google.com/search?hl=en&q...=Google+Search

DHTML is the term used for client-side scripting (using CSS or not) that
makes things move and change based on user action. Whether that's "official"
or not is irrelevant. It's the commonly used term for it. You can say
Kleenex, or you can say "the tissue you wipe your snot with and blow your
nose in". The choice is yours.

--
--
~kaeli~
The definition of a will?... (It's a dead giveaway.)
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 23 '05 #15

P: n/a
kaeli wrote:
(html is NOT a programming language; it's strictly a layout
mechanism)


Pardon? How does one use html as a layout mechanism?

--
Brian (remove "invalid" to email me)
Jul 23 '05 #16

P: n/a
In article <nK*********************@bgtnsc04-news.ops.worldnet.att.net>,
us*****@julietremblay.com.invalid enlightened us with...
kaeli wrote:
(html is NOT a programming language; it's strictly a layout
mechanism)


Pardon? How does one use html as a layout mechanism?


Bad choice of wording on my part. Semantics have never been my strong point.
The point is, it isn't a programming language.

Although one easily CAN use it as a layout mechanism -- and many do,
including myself. CSS still can't do some things that are easily accomplished
with tables, at least easily and in a cross-browser manner.
Examples could be provided, but are rather outside the scope of this thread.

--
--
~kaeli~
Experience is something you don't get until just after you
need it.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 23 '05 #17

P: n/a
kaeli wrote:
us*****@julietremblay.com.invalid enlightened us with...
kaeli wrote:
(html is NOT a programming language; it's strictly a layout
mechanism)
Pardon? How does one use html as a layout mechanism?


Bad choice of wording on my part. Semantics have never been my strong
point. The point is, it isn't a programming language.


Agreed.
Although one easily CAN use it as a layout mechanism -- and many do,
including myself.
One can use a paper weight as a hammer, too. Whether that's the
appropriate tool or not becomes the question, particularly when you
smash a heavy rock into the shelf you're building, creating a big dent.
CSS still can't do some things that are easily accomplished with
tables, at least easily and in a cross-browser manner. Examples could
be provided, but are rather outside the scope of this thread.


I see no reason to start another css v. tables debate. I will point out,
though, that if you must sacrifice either layout or semantics due to
lousy browsers, I'd go for sacrificing layout.

--
Brian (remove "invalid" to email me)
Jul 23 '05 #18

P: n/a
In article <Ps******************@bgtnsc05-news.ops.worldnet.att.net>, usenet3
@julietremblay.com.invalid enlightened us with...
CSS still can't do some things that are easily accomplished with
tables, at least easily and in a cross-browser manner. Examples could
be provided, but are rather outside the scope of this thread.


I see no reason to start another css v. tables debate. I will point out,
though, that if you must sacrifice either layout or semantics due to
lousy browsers, I'd go for sacrificing layout.


Another purist. ;)
You're certainly entitled to your feelings on this, but if you notice, the
vast majority of real-world websites out there do a nice combo, using CSS for
most things, but still using tables for other things. The stuff clients
actually pay for doesn't always meet the "best" standards. They want their
sites to look a certain way. If tables are the only way to accomplish that,
then tables it is. If CSS alone can do it, wonderful! Use that.
We could all do perfectly separated content/layout that works for every
single person in the world no matter what the UA. But if it looks like hell,
or only looks great in IE and is completely fubar in Gecko browsers, clients
won't much want to pay for it just to meet the ideal of separation.
If it takes the developer three times as long to make it work in all the
major browsers, the client has to pay for that. Many will choose to go with
the simpler, cheaper design.
In a perfect world, all the browsers would support everything just the same.
CSS, javascript, and all. But they don't.
A lot of sites out there these days are about a lot more than just
informational content. They need to look good, entertain people, and do
things. They are applications more than they are just some text being
displayed on a screen. They compete for visitors. They make money for the
owners. Their purpose is not to perfectly meet every ideal of standards. It's
to make money. The better they look, the better to attract visitors. They
need to function well to KEEP visitors. No one really cares if the function
is acheived with tables or CSS or script or whatever, as long as it does
function for most people.
I tend to be a purist when it comes to script in pages, but I'm well aware
that most sites do use it, so I can tell people until I'm blue in the face
that they shouldn't rely on it, but they will. The advice then becomes advice
to try to make it work in the most browsers possible (and not crash others)
and to use server-side script to double-check things, just in case.
Compromise. :)

(as an interesting note, the most popular sites I know of, ebay and amazon,
use tables for layout for at least parts of their sites)

(that got WAY longer than I intended...*LOL*)

--
--
~kaeli~
Support your local medical examiner: die strangely!
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 23 '05 #19

P: n/a
kaeli wrote:
Brian wrote:
I see no reason to start another css v. tables debate. I will point out,
though, that if you must sacrifice either layout or semantics due to
lousy browsers, I'd go for sacrificing layout.
Another purist. ;)


Most are proud of the label.
You're certainly entitled to your feelings on this,
How generous! ;)
but if you notice, the
vast majority of real-world websites out there do a nice combo, using
CSS for
most things, but still using tables for other things.
Yes, they combine limited CSS with inappropriate usage of tables.
The stuff clients
actually pay for doesn't always meet the "best" standards. They want
their
sites to look a certain way.
I want the outlets in particular places, but if it cannot be done the
electrician advises me to stop wanting that.

I want the room to not have a pillar in the middle, but if it cannot be
done the architect advises me to stop wanting that.

I want to install some special card in my computer, but if it cannot be
done the technician advises me to stop wanting that.

Now in each of the above cases, it still can be done, but at a cost. I
submit that the cost of employing table layout is great enough to warrant
advisement. Not to mention that control over the look of a site is
ephemeral anyhow.
If tables are the only way to accomplish that,
then tables it is.
So long as you demonstrate the issues connected to table layout, and the
customer is willing to pay the price for such a design, I have no issues.
You have to run a business, and sometimes the best solution for the web
isn't the customer's desire. If you never mention the problems with table
design, I have an issue with that.
If CSS alone can do it, wonderful! Use that.
We could all do perfectly separated content/layout that works for every
single person in the world no matter what the UA. But if it looks like
hell,
or only looks great in IE and is completely fubar in Gecko browsers,
clients
won't much want to pay for it just to meet the ideal of separation.
Hmm. Nearly any competent CSS writer can develop a layout that is
consistent in all browsers. Excepting the case where what the customer
demands is one of the rare examples which is truly impossible in CSS and
possible in tables, the only excuse for the use of tables over CSS is a
lack of expertise in CSS - and certainly the designer won't be admitting
to that.
If it takes the developer three times as long to make it work in all the
major browsers, the client has to pay for that. Many will choose to go
with
the simpler, cheaper design.
Cheap is cheap. Did the company buy the $20 office chair ordid they spring
for quality? Did they buy the least expensive machinery or did they opt
for a model which is easier to modify, maintain and requires less cost to
repair?

And again, a competent CSS designer should not require three times as much
work to do the job. Unless, of course, they have not learned CSS and are
just used to tables.
In a perfect world, all the browsers would support everything just the
same.
CSS, javascript, and all. But they don't.
I disagree. In a perfect WWW, every browser is customized for the
individual user, and the author must work around this advantage, not see
it as a disadvantage.

If my guess is correct, and this is the direction we're moving in, table
layout experts better get good at CSS and fast to stay competitive.
A lot of sites out there these days are about a lot more than just
informational content. They need to look good, entertain people, and do
things. They are applications more than they are just some text being
displayed on a screen. They compete for visitors. They make money for the
owners.
Irrelevent in the tables vs CSS debate. CSS can do all these things.
Their purpose is not to perfectly meet every ideal of standards. It's
to make money. The better they look, the better to attract visitors. They
need to function well to KEEP visitors. No one really cares if the
function
is acheived with tables or CSS or script or whatever, as long as it does
function for most people.
Yep. Again, CSS can do this. Tables can as well, but with less
gracefulness than CSS.
I tend to be a purist when it comes to script in pages, but I'm well
aware
that most sites do use it, so I can tell people until I'm blue in the
face
that they shouldn't rely on it, but they will. The advice then becomes
advice
to try to make it work in the most browsers possible (and not crash
others)
and to use server-side script to double-check things, just in case.
Compromise. :)
All you need to do is have them see what the site comes out as in a no-Js
environment, such as a search engine. That usually sells the "don't rely
on scripts" angle.
(as an interesting note, the most popular sites I know of, ebay and
amazon,
use tables for layout for at least parts of their sites)


Popularity of a site is not due entirely to the layout, though it can play
a part. Ebay and Amazon also offer a very relevant set of content. If
these sites were done in the most bland layout possible, with the same
content and functionality, I doubt they would lose a cent. Content
outweighs design when the user considers what site they will use.
Jul 23 '05 #20

P: n/a
kaeli wrote:
us*****@julietremblay.com.invalid ...
I see no reason to start another css v. tables debate. I will point
out, though, that if you must sacrifice either layout or semantics
due to lousy browsers, I'd go for sacrificing layout.
Another purist. ;)


You just couldn't resist, could you? Well, neither could I. ;-)
You're certainly entitled to your feelings on this, but if you
notice, the vast majority of real-world websites out there do a nice
combo,
FYI: the sites that I produce, using css for layout, are real-world
sites. They exist for real on the www, and are used by visitors and
everything. So let's at least avoid the "get in the real world"
argument, which you hinted at here (perhaps unintentionally).
using CSS for most things, but still using tables for other things.
The stuff clients actually pay for doesn't always meet the "best"
standards.
Most certainly not, as casual browsing will attest.
They want their sites to look a certain way.
Right. They think the www is for desktop publishing. They haven't
recognized its strengths and weaknesses.
We could all do perfectly separated content/layout that works for
every single person in the world no matter what the UA. But if it
looks like hell,
There is no excuse for producing ugly pages just because you decided
against tables for layout. The www had advanced to the point where most
users can get a reasonably attractive page, since every browser produced
over the last half dozen years can do at least some css.
or only looks great in IE and is completely fubar in Gecko browsers,
Then the author hasn't done his job, right?
If it takes the developer three times as long to make it work in all
the major browsers, the client has to pay for that. Many will choose
to go with the simpler, cheaper design.
Especially if it's a business. But the costs will be greater down the
road when marketing learns that their table heavy page falls apart in
some new hand held device that took the world by storm. ("Gee, we didn't
see that coming.") And if the higher ups are clueless enough, noone will
have to pay for the shortsited decision made today to just get it to
work in MSIE, use tables, and forget about separation of content and
presentation. Ho hum. Since when have businesses looked at the long term?
In a perfect world, all the browsers would support everything just
the same. CSS, javascript, and all.
Noting that CSS and js are optional, ok.
A lot of sites out there these days are about a lot more than just
informational content. They need to look good,
I'd dispute that they need to look good. There are lots of plain or even
ugly sites that are quite popular.
entertain people, and do things. They are applications more than they
are just some text being displayed on a screen.
You have created a weird, and I'd say false, dichotomy. Information
sometimes does entertain us, or help us accomplish tasks.
They compete for visitors. They make money for the owners. Their
purpose is not to perfectly meet every ideal of standards. It's to
make money. The better they look, the better to attract visitors.
They need to function well to KEEP visitors.
You keep mentioning functionality and attractiveness in the same breath,
as if they were interchangeable. I'd argue that they most certainly are
not. Functionality will attract and keep users, but how do you know that
a more visually attractive site will do the same?
No one really cares if the function is acheived with tables or CSS or
script or whatever, as long as it does function for most people.
Indeed, no one cares, they just want it to work. Why then would markup
abuse be necessary?
(as an interesting note, the most popular sites I know of, ebay and
amazon, use tables for layout for at least parts of their sites)


And they are popular *because* they use tables for layout? Or in spite
of that fact? Heck, I think eBay is ugly *and* badly coded. And a
usability nightmare. I use it anyways. That should tell you something.
The www is still a content driven pull technology.

--
Brian (remove "invalid" to email me)
Jul 23 '05 #21

This discussion thread is closed

Replies have been disabled for this discussion.